ai-ops-cli 1.1.1 → 1.2.0

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/README.ko.md CHANGED
@@ -2,9 +2,9 @@
2
2
 
3
3
  [English](./README.md)
4
4
 
5
- `ai-ops-cli`는 프로젝트에 AI agent operating layer 설치하고, 사용자 환경에 agent skills/subagents를 설치하는 CLI입니다.
5
+ `ai-ops-cli`는 프로젝트/에이전트 작업에 필요한 operating layer global runtime integration을 설치하고 관리하는 CLI입니다.
6
6
 
7
- 이 문서는 현재 구현된 breaking model을 설명합니다. old rules + skills scaffolder 모델은 deprecated 문맥으로만 남깁니다.
7
+ 이 문서는 현재 구현된 breaking model을 설명합니다. 현재 CLI는 bundled user/global runtime workflow를 위한 `integration` 명령을 제공하고, skill, subagent, Codex hook, user-local receipt를 다루는 low-level component 명령도 계속 제공합니다. old rules + skills scaffolder 모델은 deprecated 문맥으로만 남깁니다.
8
8
 
9
9
  ## Current Breaking Model
10
10
 
@@ -16,19 +16,23 @@ flowchart TD
16
16
  layer --> docs["docs/agent/* / docs/business/*"]
17
17
  layer --> state[".ai-ops/manifest.json / context-layer.json"]
18
18
 
19
- skill["ai-ops skill ..."] --> globalSkills["Global skills only"]
20
- subagent["ai-ops subagent ..."] --> globalSubagents["Global subagents only"]
19
+ skill["ai-ops skill ..."] --> skillComponent["Skill components"]
20
+ subagent["ai-ops subagent ..."] --> subagentComponent["Subagent components"]
21
+ integration["ai-ops integration ..."] --> integrationComponent["Runtime integration bundles"]
22
+ hook["ai-ops codex-hook ..."] --> hookComponent["Codex hook components"]
23
+ receipt["ai-ops context-promotion ..."] --> receiptComponent["User-local receipts"]
21
24
  pack["ai-ops pack ..."] --> docsSpecs["optional docs/specs/ pack"]
22
25
  ```
23
26
 
24
27
  핵심 경계:
25
28
 
26
29
  - project scope는 operating layer 문서만 관리합니다.
27
- - global scope는 skills/subagents만 관리합니다.
30
+ - integration scope는 user/global runtime workflow만 관리합니다.
31
+ - skill, subagent, Codex hook, user-local receipt/config는 integration component입니다.
28
32
  - `AGENTS.md`가 canonical entrypoint입니다.
29
33
  - `GEMINI.md`와 `CLAUDE.md`는 `AGENTS.md`를 기준으로 삼게 하는 adapter입니다.
30
34
  - `docs/specs/`는 optional pack 위치입니다.
31
- - global asset 명령은 `AI_OPS_HOME` 또는 `HOME`이 없으면 cwd fallback 없이 실패합니다.
35
+ - integration component 명령은 `AI_OPS_HOME` 또는 `HOME`이 없으면 cwd fallback 없이 실패합니다.
32
36
 
33
37
  ## 설치 대상
34
38
 
@@ -54,11 +58,13 @@ docs/docs-status.md
54
58
 
55
59
  `docs/agent/rules/00-agent-baseline.md`는 기존 `role-persona`, `communication`, `code-philosophy`, `naming-convention`, `plan-mode`의 기본 의도를 새 operating layer 문서로 이관한 Active 규칙입니다. `AGENTS.md` 직후 먼저 읽습니다.
56
60
 
57
- Global tool home:
61
+ User/global runtime component home:
58
62
 
59
63
  ```text
60
64
  skills/*
61
65
  subagents/*
66
+ hooks/*
67
+ receipts/config/*
62
68
  ```
63
69
 
64
70
  ## 수정 FAQ
@@ -92,15 +98,32 @@ Commands:
92
98
  update Re-apply the project operating layer
93
99
  audit Check frontmatter, docs-status, manifest, and context-layer consistency
94
100
  uninstall Remove project-managed operating layer files
95
- skill Manage global agent skills
96
- subagent Manage global agent subagents
101
+ skill Manage skill components
102
+ subagent Manage subagent components
97
103
  pack Manage optional project operating layer packs
104
+ integration Manage user/global runtime integrations
98
105
  context-promotion Manage context promotion review receipts
99
- codex-hook Manage Codex hook integration
106
+ codex-hook Manage Codex hook components
100
107
  ```
101
108
 
102
109
  `--tool`은 유지합니다. Codex, Claude Code, Gemini CLI가 서로 다른 discovery 위치와 adapter 파일을 사용하기 때문입니다.
103
110
 
111
+ Integration lifecycle 명령:
112
+
113
+ ```bash
114
+ ai-ops integration list
115
+ ai-ops integration install context-promotion
116
+ ai-ops integration install pc
117
+ ai-ops integration status pc
118
+ ai-ops integration uninstall pc
119
+ ```
120
+
121
+ `context-promotion`은 `context-promotion-review` Codex skill, Codex `PostToolUse` hook, user-local receipt workflow를 묶습니다.
122
+
123
+ `pc`는 `pc` Codex skill과 Codex `PostToolUse` hook runner를 묶습니다. 성공적인 `git commit` 이후 `~/.personal-project-contexts/`에 matching workspace, active workstream, current repo scope가 이미 준비된 경우에만 Codex가 `$pc:done`으로 이어가게 합니다.
124
+
125
+ Integration 소유권은 user/global runtime home의 `.ai-ops/integrations-manifest.json`에 기록합니다. Uninstall은 owned component만 제거하고 기존 수동 설치는 보존합니다.
126
+
104
127
  Skill lifecycle 명령:
105
128
 
106
129
  ```bash
@@ -115,7 +138,9 @@ ai-ops skill uninstall skill-load-check
115
138
 
116
139
  `doc-impact-reviewer`는 변경 완료 또는 커밋 직전에 운영 문서 영향도를 확인하는 수동 task skill입니다. `$doc-impact-reviewer`로 호출하면 git status/diff를 보고 `required / recommended / not needed` 문서 후보와 미갱신 리스크를 제안합니다. 사용자 승인 전에는 문서를 수정하지 않고, 직접 staging/commit도 하지 않습니다.
117
140
 
118
- `context-promotion-review`는 방금 만든 작업 커밋에서 core, project-local, global로 승격할 반복 운영 지식이 생겼는지 확인하는 Codex 전용 task skill입니다. Codex hook은 `git commit` 이후에 동작하며 작업 커밋을 막지 않습니다. hook 설치 시 Codex skill도 global 위치에 함께 설치합니다. 승인된 승격 수정은 사용자 검사를 위해 커밋하지 않은 상태로 남기고, 최종 결정은 `ai-ops context-promotion resolve`로 receipt에 기록합니다.
141
+ `context-promotion-review`는 방금 만든 작업 커밋에서 core, project-local, global로 승격할 반복 운영 지식이 생겼는지 확인하는 Codex 전용 task skill입니다. Codex hook은 `git commit` 이후에 동작하며 작업 커밋을 막지 않습니다. hook 설치 시 Codex skill도 user/global runtime 위치에 함께 설치합니다. 승인된 승격 수정은 사용자 검사를 위해 커밋하지 않은 상태로 남기고, 최종 결정은 `ai-ops context-promotion resolve`로 receipt에 기록합니다.
142
+
143
+ Low-level component 명령도 직접 skill, hook, receipt를 관리할 때 계속 사용할 수 있습니다.
119
144
 
120
145
  Context promotion과 Codex hook 명령:
121
146
 
@@ -139,7 +164,7 @@ ai-ops subagent update
139
164
  ai-ops subagent uninstall security-gate
140
165
  ```
141
166
 
142
- Subagent는 항상 global tool home에 설치됩니다. Codex는 `.codex/agents/<id>.toml`, Claude Code는 `.claude/agents/<id>.md`, Gemini CLI는 `.gemini/agents/<id>.md`를 사용하고, 상태는 `.ai-ops/subagents-manifest.json`에만 기록합니다.
167
+ Subagent는 항상 user/global runtime home에 설치됩니다. Codex는 `.codex/agents/<id>.toml`, Claude Code는 `.claude/agents/<id>.md`, Gemini CLI는 `.gemini/agents/<id>.md`를 사용하고, 상태는 `.ai-ops/subagents-manifest.json`에만 기록합니다.
143
168
 
144
169
  Pack lifecycle 명령:
145
170
 
package/README.md CHANGED
@@ -2,9 +2,9 @@
2
2
 
3
3
  [Korean](./README.ko.md)
4
4
 
5
- `ai-ops-cli` installs an AI agent operating layer into a project and installs reusable agent skills/subagents into the user's global tool environment.
5
+ `ai-ops-cli` installs and manages the operating layer and global runtime integrations needed for project/agent work.
6
6
 
7
- This document describes the currently implemented breaking model. The old rules + skills scaffolder model remains only as deprecated context.
7
+ This document describes the currently implemented breaking model. The current CLI exposes `integration` commands for bundled user/global runtime workflows and keeps low-level component commands for skills, subagents, Codex hooks, and user-local receipts. The old rules + skills scaffolder model remains only as deprecated context.
8
8
 
9
9
  ## Current Breaking Model
10
10
 
@@ -16,19 +16,23 @@ flowchart TD
16
16
  layer --> docs["docs/agent/* / docs/business/*"]
17
17
  layer --> state[".ai-ops/manifest.json / context-layer.json"]
18
18
 
19
- skill["ai-ops skill ..."] --> globalSkills["Global skills only"]
20
- subagent["ai-ops subagent ..."] --> globalSubagents["Global subagents only"]
19
+ skill["ai-ops skill ..."] --> skillComponent["Skill components"]
20
+ subagent["ai-ops subagent ..."] --> subagentComponent["Subagent components"]
21
+ integration["ai-ops integration ..."] --> integrationComponent["Runtime integration bundles"]
22
+ hook["ai-ops codex-hook ..."] --> hookComponent["Codex hook components"]
23
+ receipt["ai-ops context-promotion ..."] --> receiptComponent["User-local receipts"]
21
24
  pack["ai-ops pack ..."] --> docsSpecs["optional docs/specs/ pack"]
22
25
  ```
23
26
 
24
27
  Core boundaries:
25
28
 
26
29
  - Project scope manages only operating-layer documents.
27
- - Global scope manages only skills/subagents.
30
+ - Integration scope manages only user/global runtime workflow.
31
+ - Skills, subagents, Codex hooks, and user-local receipts/config are integration components.
28
32
  - `AGENTS.md` is the canonical entrypoint.
29
33
  - `GEMINI.md` and `CLAUDE.md` are adapters that point tools back to `AGENTS.md`.
30
34
  - `docs/specs/` is the optional pack location.
31
- - Global asset commands require `AI_OPS_HOME` or `HOME`; they fail closed without cwd fallback when neither exists.
35
+ - Integration component commands require `AI_OPS_HOME` or `HOME`; they fail closed without cwd fallback when neither exists.
32
36
 
33
37
  ## Install Targets
34
38
 
@@ -54,11 +58,13 @@ docs/docs-status.md
54
58
 
55
59
  `docs/agent/rules/00-agent-baseline.md` is the Active rule that carries the original intent of the old `role-persona`, `communication`, `code-philosophy`, `naming-convention`, and `plan-mode` rules into the new operating layer. It is read immediately after `AGENTS.md`.
56
60
 
57
- Global tool home:
61
+ User/global runtime component home:
58
62
 
59
63
  ```text
60
64
  skills/*
61
65
  subagents/*
66
+ hooks/*
67
+ receipts/config/*
62
68
  ```
63
69
 
64
70
  ## Editing FAQ
@@ -92,15 +98,32 @@ Commands:
92
98
  update Re-apply the project operating layer
93
99
  audit Check frontmatter, docs-status, manifest, and context-layer consistency
94
100
  uninstall Remove project-managed operating layer files
95
- skill Manage global agent skills
96
- subagent Manage global agent subagents
101
+ skill Manage skill components
102
+ subagent Manage subagent components
97
103
  pack Manage optional project operating layer packs
104
+ integration Manage user/global runtime integrations
98
105
  context-promotion Manage context promotion review receipts
99
- codex-hook Manage Codex hook integration
106
+ codex-hook Manage Codex hook components
100
107
  ```
101
108
 
102
109
  `--tool` remains because Codex, Claude Code, and Gemini CLI use different discovery locations and adapter files.
103
110
 
111
+ Integration lifecycle commands:
112
+
113
+ ```bash
114
+ ai-ops integration list
115
+ ai-ops integration install context-promotion
116
+ ai-ops integration install pc
117
+ ai-ops integration status pc
118
+ ai-ops integration uninstall pc
119
+ ```
120
+
121
+ `context-promotion` bundles the `context-promotion-review` Codex skill, a Codex `PostToolUse` hook, and user-local receipt workflow.
122
+
123
+ `pc` bundles the `pc` Codex skill and a Codex `PostToolUse` hook runner. It prompts Codex to run `$pc:done` after a successful `git commit` only when `~/.personal-project-contexts/` already has a matching workspace, active workstream, and current repo scope.
124
+
125
+ Integration ownership is tracked in `.ai-ops/integrations-manifest.json` under the user/global runtime home. Uninstall removes only owned components and preserves pre-existing manual installs.
126
+
104
127
  Skill lifecycle commands:
105
128
 
106
129
  ```bash
@@ -115,7 +138,9 @@ ai-ops skill uninstall skill-load-check
115
138
 
116
139
  `doc-impact-reviewer` is a manual task skill for checking operating-document impact near the end of work or before commit. Invoking `$doc-impact-reviewer` reads git status/diff and reports document update candidates as `required / recommended / not needed`. It does not edit documents, stage files, or commit before user approval.
117
140
 
118
- `context-promotion-review` is a Codex-only task skill for checking whether the just-created work commit produced reusable operating knowledge that should be promoted to core, project-local, or global context. The Codex hook runs after `git commit`, never blocks the work commit, and any approved promotion edits stay uncommitted until the user reviews them. Installing the hook also installs the Codex skill globally. It records the final decision with `ai-ops context-promotion resolve`.
141
+ `context-promotion-review` is a Codex-only task skill for checking whether the just-created work commit produced reusable operating knowledge that should be promoted to core, project-local, or global context. The Codex hook runs after `git commit`, never blocks the work commit, and any approved promotion edits stay uncommitted until the user reviews them. Installing the hook also installs the Codex skill into the user/global runtime location. It records the final decision with `ai-ops context-promotion resolve`.
142
+
143
+ Low-level component commands remain available for direct skill, hook, and receipt management.
119
144
 
120
145
  Context promotion and Codex hook commands:
121
146
 
@@ -139,7 +164,7 @@ ai-ops subagent update
139
164
  ai-ops subagent uninstall security-gate
140
165
  ```
141
166
 
142
- Subagents are always installed into the global tool home. Codex uses `.codex/agents/<id>.toml`, Claude Code uses `.claude/agents/<id>.md`, Gemini CLI uses `.gemini/agents/<id>.md`, and state is recorded only in `.ai-ops/subagents-manifest.json`.
167
+ Subagents are always installed into the user/global runtime home. Codex uses `.codex/agents/<id>.toml`, Claude Code uses `.claude/agents/<id>.md`, Gemini CLI uses `.gemini/agents/<id>.md`, and state is recorded only in `.ai-ops/subagents-manifest.json`.
143
168
 
144
169
  Pack lifecycle commands:
145
170
 
@@ -19,4 +19,5 @@ update_when:
19
19
  ## 범위
20
20
 
21
21
  - project scope: `AGENTS.md`, `GEMINI.md`, `CLAUDE.md`, `docs/agent/*`, `docs/business/*`, `docs/docs-status.md`, `.ai-ops/*`
22
- - global scope: skills, subagents, tool-specific reusable assets
22
+ - integration scope: user/global runtime integrations and their components
23
+ - component scope: skills, subagents, Codex hooks, hook runners, user-local receipts/config
@@ -22,4 +22,4 @@ update_when:
22
22
 
23
23
  - 사용자 변경으로 보이는 diff는 되돌리지 않는다.
24
24
  - project-owned 문서는 CLI update가 덮어쓰지 않는다.
25
- - global skillssubagents는 project operating layer uninstall 대상이 아니다.
25
+ - user/global integrations그 component는 project operating layer uninstall 대상이 아니다.
@@ -0,0 +1,44 @@
1
+ {
2
+ "integrations": [
3
+ {
4
+ "id": "context-promotion",
5
+ "description": "Codex git-commit 후 context promotion review receipt를 요구하는 integration",
6
+ "components": [
7
+ {
8
+ "type": "skill",
9
+ "id": "context-promotion-review",
10
+ "tools": ["codex"]
11
+ },
12
+ {
13
+ "type": "codex-hook",
14
+ "id": "context-promotion"
15
+ },
16
+ {
17
+ "type": "receipt-config",
18
+ "id": "context-promotion-receipts",
19
+ "storage_path": ".ai-ops/context-promotion/projects/*/receipts-index.json"
20
+ }
21
+ ]
22
+ },
23
+ {
24
+ "id": "pc",
25
+ "description": "Codex git-commit 후 $pc:done handoff를 요구하는 personal context integration",
26
+ "components": [
27
+ {
28
+ "type": "skill",
29
+ "id": "pc",
30
+ "tools": ["codex"]
31
+ },
32
+ {
33
+ "type": "codex-hook",
34
+ "id": "pc"
35
+ },
36
+ {
37
+ "type": "receipt-config",
38
+ "id": "personal-project-contexts",
39
+ "storage_path": "~/.personal-project-contexts"
40
+ }
41
+ ]
42
+ }
43
+ ]
44
+ }
@@ -128,6 +128,14 @@
128
128
  "included_in_presets": [],
129
129
  "source_path": "task-skills/context-promotion-review"
130
130
  },
131
+ {
132
+ "id": "pc",
133
+ "kind": "task",
134
+ "supported_tools": ["codex"],
135
+ "groups": ["agent-operating-layer"],
136
+ "included_in_presets": [],
137
+ "source_path": "task-skills/pc"
138
+ },
131
139
  {
132
140
  "id": "skill-load-check",
133
141
  "kind": "task",
@@ -0,0 +1,266 @@
1
+ ---
2
+ name: pc
3
+ description: Use only when the user explicitly invokes $pc, $pc:help, $pc:init, $pc:add, $pc:todo, $pc:do, or $pc:done for personal workspace/repo/service context loading, task intake, active workstream selection, and handoff.
4
+ disable-model-invocation: true
5
+ ---
6
+
7
+ # pc
8
+
9
+ 개인 workspace 컨텍스트를 `~/.personal-project-contexts/`에 보관하고, 현재 경로와 매칭해 작업 시작/착수/종료 맥락을 수동으로 불러오는 skill이다. 단일 repo, monorepo, monorepo-like, git이 없는 MSA folder 묶음을 모두 workspace로 다룬다.
10
+
11
+ ## Invocation
12
+
13
+ - 이 skill은 사용자가 `$pc`, `$pc:help`, `$pc:init`, `$pc:add`, `$pc:todo`, `$pc:do`, `$pc:done`을 명시했을 때만 사용한다.
14
+ - `$pc`는 `$pc:todo`와 동일하게 처리한다.
15
+ - 알 수 없는 subcommand는 파일을 수정하지 말고 `$pc:help` 형식으로 사용법을 안내한다.
16
+ - 모든 사용자-facing 응답은 한국어로 작성한다. 파일 경로, command, code identifier는 원문을 유지한다.
17
+
18
+ ## Language Rules
19
+
20
+ - context repo에 생성/갱신하는 Markdown 산출물은 한국어를 기본으로 쓴다.
21
+ - Markdown 제목과 필드 라벨도 한국어로 쓴다. 예: `## 식별`, `- 워크스페이스 ID:`, `## 현재 방향`.
22
+ - 고유명사, 전문 용어, repo 이름, 파일 경로, branch, package/library/service name, API field, command, protocol은 원문을 유지한다.
23
+ - `git-repo`, `monorepo-package`, `folder-service`, `git`, `none` 같은 enum 값은 원문을 유지한다.
24
+ - 외부 문서에서 가져온 고유 명칭은 무리하게 번역하지 말고, 설명 문장만 한국어로 요약한다.
25
+
26
+ ## Context Store
27
+
28
+ ```txt
29
+ ~/.personal-project-contexts/
30
+ workspaces/
31
+ <workspace-id>/
32
+ workspace-state.md
33
+ backlog.md
34
+ repos/
35
+ <entry-id>.md
36
+ workstreams/
37
+ <workstream-slug>.md
38
+ daily/
39
+ YYYY-MM-DD.md
40
+ ```
41
+
42
+ - 기본 저장소 경로는 `~/.personal-project-contexts/`로 고정한다.
43
+ - `workspaces/<workspace-id>/`는 제품/도메인/작업 묶음의 장기 맥락을 담는다.
44
+ - `repos/<entry-id>.md`는 이름은 `repos`지만 git repo, monorepo package, git 없는 folder service를 모두 기록하는 entry 파일이다.
45
+ - `workstreams/*.md`가 실제 로딩/언로딩 단위이며, `범위` 섹션에 영향 entry를 명시한다.
46
+ - `backlog.md`는 느슨한 할 일 inbox가 아니라 등록된 workstream의 상태 index다.
47
+ - 자세한 파일 양식이 필요하면 [references/templates.md](references/templates.md)를 읽는다.
48
+
49
+ ## Path Rules
50
+
51
+ - `$pc:init [--reset] [path...]`의 path는 상대경로, 절대경로, `~` 경로를 허용한다.
52
+ - 인자가 없으면 `$pc:init .`와 동일하게 처리한다.
53
+ - 상대경로는 현재 작업 디렉터리 기준으로 해석하고, 저장할 때는 absolute path로 normalize한다.
54
+ - 존재하지 않는 path는 생성하지 않는다. 어떤 파일도 수정하지 말고 존재하지 않는 path를 알려준다.
55
+ - monorepo-like sibling repo/service를 이름만 보고 무작정 흡수하지 않는다.
56
+ - 단, `$pc:init .` 대상 folder 안에 `WORKSPACE_CODE_MAP.md`, child `.git`, `package.json`, `pubspec.yaml`, `pyproject.toml`, `go.mod`, `Cargo.toml` 같은 강한 증거가 있으면 evidence-based discovery로 entry 후보를 등록한다.
57
+
58
+ ## Bootstrap Discovery
59
+
60
+ `$pc:init`은 빈 템플릿 생성이 아니라 첫 재진입에 쓸 수 있는 context bootstrap이다. 쓰기 전에 다음을 먼저 읽고 요약한다.
61
+
62
+ - workspace root의 `WORKSPACE_CODE_MAP.md`, `README.md`, `AGENTS.md`, `CLAUDE.md`, `.codex/plans/*.md`, `specs/*.md`
63
+ - 명시 path와 강한 후보 child directory의 repo metadata: `.git`, remote URL, default branch
64
+ - stack/command manifest: `package.json`, `pubspec.yaml`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `Makefile`, `justfile`
65
+ - product/spec hints: `docs/`, `specs/`, `frontend/`, `api/`, `lib/`, `apps/`, `packages/`
66
+
67
+ Discovery quality floor:
68
+
69
+ - `Overview`에는 generic 문장 대신 workspace가 무엇을 만드는지와 주요 surface를 적는다.
70
+ - `Entries`에는 강한 증거가 있는 child repo/service를 등록한다. 예: child `.git` repo, workspace map에 명시된 repo, manifest가 있는 app/API folder.
71
+ - git 없는 parent folder에 강한 child entry가 있으면 parent는 보통 container로만 쓰고, 단일 `folder-service` entry로 대체하지 않는다.
72
+ - `현재 방향`, `엔트리 간 주의사항`, `공통 명령`, entry별 `기술 스택`/`명령`은 읽은 evidence에서 채운다.
73
+ - 충분한 evidence가 있는데도 비어 있는 placeholder를 남기지 않는다. 정말 알 수 없을 때만 빈 값으로 두고, 어떤 evidence가 부족했는지 `Notes`에 남긴다.
74
+ - discovery 결과가 애매하면 쓰기 전에 후보 entries와 근거를 짧게 보여주고 확인을 요청한다.
75
+
76
+ ## Existing Context Refresh
77
+
78
+ 이미 workspace context가 있을 때 `$pc:init [path...]`를 다시 실행하면 no-op이 아니라 evidence refresh로 처리한다.
79
+
80
+ - `backlog.md`, `workstreams/`, `daily/`, 사용자 handoff 기록은 보존한다.
81
+ - 누락된 child entries를 새로 추가한다.
82
+ - 기존 entry가 명백히 잘못된 bootstrap 산출물인 경우 보정한다. 예: git 없는 parent folder가 단일 `folder-service`로 등록됐지만, `WORKSPACE_CODE_MAP.md`나 child `.git` repo가 강한 child entries를 가리키는 경우.
83
+ - generic placeholder 문장만 evidence 기반 한국어 문장으로 교체한다. 예: `Personal workspace context for ...`, "현재 구체적인 active workstream은 아직..." 같은 초기 filler.
84
+ - 이전 템플릿으로 생성된 영어 Markdown 제목과 필드 라벨은 한국어로 정규화한다. 사용자 내용, 고유명사, 전문 용어, command, path, enum 값은 보존한다.
85
+ - 사용자가 직접 쓴 결정, 주의사항, handoff, backlog 항목은 삭제하지 않는다.
86
+ - full reset은 사용자가 명시적으로 요청하거나 `$pc:init --reset [path...]`를 쓴 경우에만 한다. reset 전에는 기존 `workspaces/<workspace-id>/`를 context repo 안의 `backups/<timestamp>-<workspace-id>/`로 복사한 뒤 진행한다.
87
+
88
+ ## Workspace and Entry Detection
89
+
90
+ - workspace root:
91
+ - path가 하나면, 해당 path가 git repo 안에 있을 때 git root를 workspace root로 쓰고, git repo가 아니면 해당 folder를 workspace root로 쓴다.
92
+ - path가 여러 개이고 모두 같은 git root 안에 있으면 그 git root를 workspace root로 쓴다.
93
+ - path가 여러 개이고 서로 다른 git root 또는 git 없는 folder를 가리키면, 현재 작업 디렉터리가 모든 path의 ancestor일 때 현재 작업 디렉터리를 workspace root로 쓰고, 아니면 공통 ancestor를 쓴다.
94
+ - workspace id는 workspace root basename을 slug로 만들고, 충돌하면 remote owner/repo 또는 짧은 path hash를 덧붙인다.
95
+ - entry id는 entry path basename을 slug로 만들고, 충돌하면 상위 폴더 slug를 덧붙인다.
96
+ - entry type:
97
+ - `git-repo`: entry path가 git root와 같을 때
98
+ - `monorepo-package`: entry path가 git root 아래의 명시 path일 때
99
+ - `folder-service`: entry path가 git repo 밖의 folder일 때
100
+ - git 없는 workspace root 아래에 여러 강한 child entry가 있으면 workspace root 자체를 `folder-service`로 등록하지 말고, child entries를 등록한다.
101
+ - `monorepo-package`는 `VCS: git`, `Git Root: <workspace-git-root>`를 기록한다.
102
+ - `folder-service`는 `VCS: none`으로 기록하고 git command를 요구하지 않는다.
103
+
104
+ ## Matching Rules
105
+
106
+ - 현재 absolute path로 `workspaces/*/workspace-state.md`의 `Workspace Root` ancestor match를 찾는다.
107
+ - 그 안에서 `repos/*.md`의 `Path` 또는 `Git Root` 중 현재 path를 가장 구체적으로 포함하는 entry를 current entry로 고른다.
108
+ - 여러 workspace가 동시에 매칭되면 가장 긴 `Workspace Root`를 우선한다.
109
+ - 동률이거나 애매하면 read-only 명령은 후보를 보여주고, 쓰기 명령은 파일을 수정하지 말고 사용자가 workspace를 더 명확히 지정하게 한다.
110
+
111
+ ## Workstream Lifecycle
112
+
113
+ workstream이 이 skill의 핵심 작업 단위다.
114
+
115
+ - `$pc:add <항목>`은 새 workstream을 등록한다.
116
+ - `$pc:todo`는 read-only로 진행중/미완료 workstream들을 보여준다.
117
+ - `$pc:do <항목>`은 등록된 workstream을 진행중으로 전환하거나 오늘 진행 대상으로 갱신한다.
118
+ - `$pc:done`은 진행중 workstream의 오늘 진행 상황, 완료 여부, 남은 일, 다음 첫 행동을 기록한다.
119
+ - workstream 상태는 `Planned`, `Active`, `Paused`, `Done` 중 하나를 기본으로 쓴다.
120
+ - `backlog.md`는 `Planned`, `Active`, `Paused`, `Done` workstream을 찾기 위한 얇은 index이며, 상세 맥락은 `workstreams/<slug>.md`에 둔다.
121
+ - git 기반 entry는 workstream에 마지막 확인 commit hash를 기록해 다음 `$pc:done`에서 incremental handoff를 만들 수 있게 한다.
122
+
123
+ ## Next Action Quality Rules
124
+
125
+ `다음 첫 행동`은 오래된 메모를 그대로 복사하지 말고, 매번 현재 evidence로 재검증한다.
126
+
127
+ - source of truth 우선순위는 사용자 제공 완료/남은 일/다음 행동, 새 commit/diff evidence, 참조 문서의 phase/scope, 실제 파일/manifest 상태, 기존 workstream 메모 순서다.
128
+ - `남은 일`이나 기존 `다음 첫 행동`에 있는 항목이라도 이미 완료됐거나 현재 phase의 제외 범위에 있으면 다음 행동으로 쓰지 않는다.
129
+ - 참조 문서가 `Phase N`, `포함`, `제외`, `완료 기준`을 명시하면 그 경계를 반영한다. 사용자가 "Phase N까지 완료"라고 말했으면 다음 행동은 Phase N 내부의 오래된 task가 아니라 다음 미완료 phase나 검증/정리 행동에서 고른다.
130
+ - 특정 파일/테스트를 다음 행동으로 제안하기 전에 `rg --files`, manifest, 현재 코드 구조로 그 파일/테스트/스크립트가 이미 있는지 확인한다.
131
+ - repo에 test runner나 script가 없는데 "unit test 추가"처럼 단정하지 않는다. 먼저 "검증 방식 결정" 또는 "작은 검증 스크립트 추가"처럼 실제 repo 상태에 맞는 행동으로 쓴다.
132
+ - evidence가 엇갈리면 단정하지 말고 `추정`임을 표시하고, 어떤 확인이 필요한지 함께 남긴다.
133
+ - `$pc:todo`는 read-only이므로 stale한 `다음 첫 행동`을 발견하면 파일을 고치지 않고 응답에서 보정해 말한다.
134
+
135
+ ## Workstream Intake Compression
136
+
137
+ 사용자가 `$pc:add <제목>`와 함께 긴 계획서, sprint 문서, POC 설계서, phase 목록, 테스트 계획을 붙여넣거나 `@mention`으로 문서를 제공하면 workstream 초기 본문으로 압축한다.
138
+
139
+ - 이미 목표/범위/phase/테스트/성공 기준이 있는 문서는 `$pc:add` 입력으로 본다.
140
+ - 원문 전체를 그대로 저장하지 않는다. 재진입에 필요한 운영 맥락으로 압축한다.
141
+ - `@mention` 또는 파일 경로로 제공된 문서는 `참조 문서` 섹션에 문서명, absolute path, 역할을 기록한다.
142
+ - 채팅에만 붙여넣은 원문은 `참조 문서`에 `사용자 제공 계획서`, `경로: none`으로 기록한다.
143
+ - `목표`에는 workstream의 핵심 질문과 완료 기준을 2-5문장으로 요약한다.
144
+ - `범위`에는 관련 entries를 기록한다. 문서에 명시된 파일 경로, package, API route, dashboard, client surface를 보고 추론하되 애매하면 current entry를 기본값으로 둔다.
145
+ - `현재 상태`에는 완료된 phase, 이미 존재하는 기반, 현재 branch/작업 상태를 요약한다.
146
+ - `남은 일`에는 곧 작업할 phase를 체크리스트로 변환한다.
147
+ - `다음 첫 행동`은 바로 실행 가능한 하나의 행동으로 좁히고, `Next Action Quality Rules`에 맞게 참조 문서의 phase/scope와 실제 repo 상태를 확인한다.
148
+ - `열린 질문`에는 구현 전 확인이 필요한 모호점만 남긴다.
149
+ - `메모`에는 PII, 보안, 배포 금지, dashboard 노출 제한, 제외 범위 같은 작업 중 잊으면 안 되는 제약을 남긴다.
150
+ - `backlog.md`에는 workstream title, status, 범위 entries, workstream file path만 요약한다.
151
+
152
+ ## Safety Rules
153
+
154
+ - 작업 workspace/repo/service 안에는 이 skill의 context 파일을 만들거나 수정하지 않는다.
155
+ - `$pc:help`와 `$pc:todo`는 read-only다. 어떤 파일도 수정하지 않는다.
156
+ - `$pc:init`, `$pc:add`, `$pc:do`, `$pc:done`은 `~/.personal-project-contexts/`만 수정한다.
157
+ - context store를 수정한 뒤에는 해당 context repo에서만 commit한다.
158
+ - 기존 context 파일의 사용자 기록을 삭제하지 않는다. 상태 변경은 append 또는 좁은 섹션 갱신으로 처리한다.
159
+ - 작업 repo의 변경을 stage/commit/revert하지 않는다.
160
+
161
+ ## Command Workflow
162
+
163
+ ### `$pc:help`
164
+
165
+ 사용 가능한 subcommand와 사용 시점을 짧게 출력한다.
166
+
167
+ - `$pc` / `$pc:todo`: 현재 workspace 맥락과 다음 행동 확인
168
+ - `$pc:init [--reset] [path...]`: 현재 또는 명시 path를 workspace entry로 등록하거나 재생성
169
+ - `$pc:add <항목>`: 새 workstream을 등록하고 큰 계획 문서는 초기 본문으로 압축
170
+ - `$pc:do <항목>`: 등록된 workstream을 진행중으로 설정하거나 오늘 작업 대상으로 갱신
171
+ - `$pc:done`: 진행중 workstream의 진행/완료/handoff를 저장
172
+
173
+ ### `$pc:init [--reset] [path...]`
174
+
175
+ 1. path 인자가 없으면 `.`를 사용한다. `--reset`은 path로 보지 않는다.
176
+ 2. 모든 path를 normalize하고 존재 여부를 확인한다.
177
+ 3. `Bootstrap Discovery` 규칙으로 workspace map, docs, manifests, child repo/service 후보를 읽는다.
178
+ 4. workspace root와 entry 목록을 `Workspace and Entry Detection` 규칙으로 정한다.
179
+ 5. `~/.personal-project-contexts/`가 없으면 만들고 git repo로 초기화한다.
180
+ 6. `workspaces/<workspace-id>/workspace-state.md`, `backlog.md`, `repos/`, `workstreams/`, root-level `daily/`를 만든다.
181
+ 7. 기존 workspace가 있고 `--reset`이 없으면 `Existing Context Refresh` 규칙에 따라 보존/보정한다.
182
+ 8. 기존 workspace가 있고 `--reset`이 있으면 `backups/<timestamp>-<workspace-id>/`에 백업한 뒤 workspace를 evidence 기반으로 다시 만든다.
183
+ 9. 각 entry의 `repos/<entry-id>.md`를 evidence 기반 한국어로 채우거나, 이미 있으면 비어 있거나 generic인 주요 섹션만 보강한다.
184
+ 10. 사용자의 현재 목표가 대화에서 명확하면 첫 workstream을 만들고 `workspace-state.md`에 active로 등록한다. 불명확하면 active workstream을 비워둔다.
185
+ 11. context repo에서 변경을 commit한다.
186
+
187
+ 초기화 후에는 workspace id, workspace root, 등록 entry, git 없는 entry 여부, 다음 추천 명령을 짧게 보고한다.
188
+
189
+ ### `$pc:add <항목>`
190
+
191
+ 1. 현재 경로와 매칭되는 workspace를 찾는다. 없으면 `$pc:init .`부터 필요하다고 안내하고 쓰지 않는다.
192
+ 2. 항목을 workstream title로 보고 `workstreams/<slug>.md`를 만든다. 이미 같은 workstream이 있으면 새 파일을 만들지 말고 기존 파일을 보강한다.
193
+ 3. 긴 계획서, phase 목록, 테스트 계획, `@mention` 문서가 함께 제공되면 `Workstream Intake Compression` 규칙으로 초기 본문과 참조 문서를 작성한다.
194
+ 4. 문서가 짧으면 목표, 범위, 현재 상태, 남은 일, 다음 첫 행동을 가능한 만큼 채우고 모르는 값은 비워두지 말고 `열린 질문`에 남긴다.
195
+ 5. 기본 상태는 `Planned`다. 사용자가 "바로 진행중으로 등록"처럼 명시하면 `Active`로 두고 `workspace-state.md`의 active workstream도 갱신한다.
196
+ 6. 영향 entry가 명확하면 workstream `범위`와 `backlog.md` index의 `후보 엔트리`에 남긴다.
197
+ 7. `backlog.md`에는 workstream title, status, 범위 entries, workstream file path만 요약해 등록한다.
198
+ 8. context repo에서 commit한다.
199
+
200
+ 응답에는 등록된 workstream, 상태, 범위 entries, 참조 문서, 다음 추천 명령을 포함한다.
201
+
202
+ ### `$pc:todo`
203
+
204
+ read-only로 현재 작업 맥락을 출력한다.
205
+
206
+ 1. 현재 경로와 매칭되는 workspace와 current entry를 찾는다.
207
+ 2. `workspace-state.md`를 얇게 읽는다.
208
+ 3. current entry가 있으면 해당 `repos/<entry-id>.md`를 읽는다.
209
+ 4. `backlog.md`에서 `Active`, `Planned`, `Paused` workstream index를 읽는다.
210
+ 5. active workstream과 current entry에 관련된 미완료 workstream을 깊게 읽는다.
211
+ 6. active workstream의 `참조 문서`, `남은 일`, `제외 범위`, `마지막 Handoff`, 현재 repo의 파일/manifest 상태를 대조해 `다음 첫 행동`이 아직 유효한지 확인한다.
212
+ 7. 아래 순서로 짧게 정리한다.
213
+ - workspace 개요
214
+ - 현재 repo/service 맥락
215
+ - 진행중 workstream
216
+ - 미완료 workstream
217
+ - 각 workstream의 남은 일
218
+ - 첫 번째 행동
219
+ - 첫 번째 행동의 근거 또는 보정 이유
220
+
221
+ context가 없으면 파일을 만들지 말고 `$pc:init .` 또는 `$pc:init ./admin ./api` 같은 예시를 제안한다.
222
+
223
+ ### `$pc:do <항목>`
224
+
225
+ 1. 현재 경로와 매칭되는 workspace를 찾는다. 없으면 쓰지 않고 `$pc:init .`을 제안한다.
226
+ 2. `<항목>`과 가장 잘 맞는 기존 workstream을 찾는다.
227
+ 3. workstream이 없으면 파일을 수정하지 말고 `$pc:add <항목>`으로 먼저 등록하라고 안내한다.
228
+ 4. 선택한 workstream 상태를 `Active`로 바꾸고 `workspace-state.md`의 active workstream으로 설정한다.
229
+ 5. 같은 workspace에 기존 active workstream이 있으면 사용자가 명시하지 않은 한 `Paused`로 바꾸거나, 애매하면 확인을 요청한다.
230
+ 6. workstream의 `오늘`, `현재 상태`, `다음 첫 행동`을 갱신한다.
231
+ 7. `backlog.md` index의 status를 함께 갱신한다.
232
+ 8. context repo에서 commit한다.
233
+
234
+ 응답에는 active workstream, 범위 entries, 오늘 목표, 다음 첫 행동을 포함한다.
235
+
236
+ ### `$pc:done`
237
+
238
+ 1. 현재 경로와 매칭되는 workspace와 active workstream을 찾는다. 없으면 쓰지 않고 `$pc:do <항목>`으로 진행중 workstream을 먼저 선택하라고 안내한다.
239
+ 2. 사용자가 완료한 일/남은 일/다음 첫 행동을 인자로 직접 제공했으면 그 내용을 우선 source of truth로 사용한다.
240
+ 3. 사용자가 `$pc:done`만 호출했으면 git 기반 entry에서 commit evidence를 수집한다.
241
+ 4. workstream에 entry별 마지막 확인 commit hash가 있으면 그 commit 이후부터 현재 `HEAD`까지의 commit log/diff summary를 본다.
242
+ 5. 마지막 확인 commit hash가 없으면 오늘 00:00 이후의 commit log를 본다.
243
+ 6. commit evidence를 본 뒤 각 git 기반 entry의 현재 `HEAD`를 workstream의 마지막 확인 commit hash로 기록한다.
244
+ 7. current entry가 git 기반이면 `git status --short`도 함께 확인해 아직 commit되지 않은 변경을 handoff에 남긴다.
245
+ 8. active workstream `범위`에 여러 git 기반 entry가 있으면 각 entry별 commit range, status/diff 확인을 시도한다.
246
+ 9. `folder-service` entry는 git commit을 요구하지 않고, 사용자 대화와 확인 가능한 파일 목록 중심으로 변경 요약을 남긴다.
247
+ 10. 참조 문서가 있으면 해당 phase/scope/제외 범위를 확인하고, 완료된 항목과 남은 항목을 evidence 기준으로 재분류한다.
248
+ 11. 다음 첫 행동을 정하기 전에 `Next Action Quality Rules`를 적용한다. 오래된 `남은 일`을 그대로 쓰지 말고, 이미 완료된 일/제외된 일/현재 repo에 없는 테스트 체계를 걸러낸다.
249
+ 12. active workstream에 오늘 완료한 일, entry별 변경 요약, commit range, 남은 일, 다음 첫 행동, 다음 행동 근거를 기록한다.
250
+ 13. workstream이 끝났으면 상태를 `Done`으로 바꾸고 `workspace-state.md`의 active workstream을 비운다. 아직 남았으면 `Active` 또는 `Paused`로 유지한다.
251
+ 14. `backlog.md` index의 status와 요약을 함께 갱신한다.
252
+ 15. `~/.personal-project-contexts/daily/YYYY-MM-DD.md`에 workspace 기준 기록을 추가하거나 갱신한다.
253
+ 16. 장기 맥락이 실제로 바뀐 경우에만 `workspace-state.md` 또는 해당 `repos/<entry-id>.md`를 갱신한다.
254
+ 17. context repo에서 commit한다.
255
+
256
+ 응답에는 context commit 요약, 오늘 완료한 일, entry별 확인 요약, 남은 일, 다음 첫 행동과 그 근거를 포함한다.
257
+
258
+ ## Commit Rules
259
+
260
+ - context repo commit message는 짧은 한국어 또는 영어 명령형으로 쓴다.
261
+ - 권장 형식:
262
+ - `Initialize workspace: <workspace-id>`
263
+ - `Add workstream: <short-title>`
264
+ - `Activate workstream: <short-title>`
265
+ - `Record handoff: YYYY-MM-DD`
266
+ - commit할 변경이 없으면 commit하지 말고 "변경 없음"으로 보고한다.
@@ -0,0 +1,6 @@
1
+ interface:
2
+ display_name: 'Project Context'
3
+ short_description: 'Personal workspace and repo context loading and handoff.'
4
+ default_prompt: 'Use $pc:todo to load the current workspace context.'
5
+ policy:
6
+ allow_implicit_invocation: false