@sumrco/cli 0.1.0 → 0.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.md +1 -1
- package/ai/modules/playbook/resources/authoring/folder-structure.rf.md +2 -0
- package/ai/modules/playbook/resources/authoring/frontmatter.rf.md +48 -15
- package/ai/modules/playbook/resources/authoring/lifecycle-hooks.rf.md +110 -0
- package/ai/modules/playbook/resources/authoring/overview.md +25 -2
- package/ai/modules/playbook/resources/team-members/playbook-technical-writer.tm.md +4 -4
- package/ai/modules/playbook/sumr.module.yaml +9 -9
- package/index.js +684 -167
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -25,6 +25,8 @@ Start with these root folders under `{{PLAYBOOK_PATH}}/` and add more as the cod
|
|
|
25
25
|
|
|
26
26
|
Keep `team-members/`, `workflows/`, and `lifecycle/` separate from `standards/` when they are repo-wide — they generate different output types and have different audiences.
|
|
27
27
|
|
|
28
|
+
When a user asks for hooks or automatic AI-tool behavior, create a lifecycle source doc rather than editing generated hook files. Use `{{PLAYBOOK_PATH}}/lifecycle/` for repo-wide session behavior and sync it into Claude/Codex hook outputs.
|
|
29
|
+
|
|
28
30
|
## Full Structure Example
|
|
29
31
|
|
|
30
32
|
```
|
|
@@ -44,23 +44,49 @@ description: "Test isolation rules, temp dir pattern, and integration test appro
|
|
|
44
44
|
| Field | Type | Purpose |
|
|
45
45
|
|-------|------|---------|
|
|
46
46
|
| `tags` | `string[]` | Freeform labels for human scanning only |
|
|
47
|
-
| `modelTier` | `reasoning \| coding \| fast` |
|
|
47
|
+
| `modelTier` | `reasoning \| coding \| fast` | Model class for team-member/agent topics. Resolved to a concrete model per channel. |
|
|
48
|
+
| `effort` | `low \| medium \| high` | Reasoning depth for team-member/agent topics. Channels that support effort emit their native knob. |
|
|
49
|
+
| `access` | `read-only \| write \| full` | Permission posture. Channels translate it into their sandbox, tool, or permission model. |
|
|
50
|
+
| `tools` | `string[]` | Agnostic capability tokens (`read`, `edit`, `shell`, `web`, `todo`, `task`). Channels translate them into native tool names or permission keys. |
|
|
48
51
|
| `channels` | object | Legacy-compatible per-channel overrides. Prefer top-level native channel blocks in new docs. |
|
|
49
52
|
| `target` | string | Output filename override (basename only, extension inferred) |
|
|
50
53
|
|
|
51
|
-
###
|
|
54
|
+
### Agent Model + Tools Axes
|
|
52
55
|
|
|
53
|
-
|
|
54
|
-
|-------|-------------|
|
|
55
|
-
| `reasoning` | `o4-mini` |
|
|
56
|
-
| `coding` | `gpt-4.1` |
|
|
57
|
-
| `fast` | `gpt-4o-mini` |
|
|
56
|
+
Declare intent once with the agnostic axes; each channel emits what it supports.
|
|
58
57
|
|
|
59
58
|
```yaml
|
|
60
|
-
modelTier: coding
|
|
59
|
+
modelTier: reasoning # reasoning | coding | fast → model class
|
|
60
|
+
effort: high # low | medium | high → Codex model_reasoning_effort
|
|
61
|
+
access: read-only # read-only | write | full → channel-native permission posture
|
|
62
|
+
tools: [read, web] # read | edit | shell | web | todo | task → channel-native tools/permissions
|
|
61
63
|
```
|
|
62
64
|
|
|
63
|
-
|
|
65
|
+
`modelTier` → concrete model per channel:
|
|
66
|
+
|
|
67
|
+
| Tier | Claude |
|
|
68
|
+
|------|--------|
|
|
69
|
+
| `reasoning` | `opus` |
|
|
70
|
+
| `coding` | `sonnet` |
|
|
71
|
+
| `fast` | `haiku` |
|
|
72
|
+
|
|
73
|
+
Claude uses the short aliases (which never drift). Other channels ship no model
|
|
74
|
+
default — pin them with `SUMR_MODEL_<CHANNEL>_<TIER>` (e.g. `SUMR_MODEL_CODEX_REASONING=o3`)
|
|
75
|
+
or a native block. Codex still derives `model_reasoning_effort` from `effort` (or
|
|
76
|
+
`modelTier`) and `sandbox_mode` from `access`.
|
|
77
|
+
|
|
78
|
+
`tools` is transformed per channel, not copied as Claude names:
|
|
79
|
+
|
|
80
|
+
| Channel | Transform |
|
|
81
|
+
|---|---|
|
|
82
|
+
| Claude | `tools: "Read, Grep, Glob, ..."` |
|
|
83
|
+
| Gemini | `tools:` array with native names such as `read_file`, `grep_search`, `web_fetch` |
|
|
84
|
+
| GitHub Copilot | `tools:` array with aliases such as `read`, `search`, `edit`, `web` |
|
|
85
|
+
| OpenCode | `permission:` object with keys such as `read`, `grep`, `edit`, `bash`, `webfetch` |
|
|
86
|
+
| Codex | no tool allowlist; `access` maps to `sandbox_mode` |
|
|
87
|
+
|
|
88
|
+
Resolution precedence (highest first): a native channel block (e.g. `codex.model`)
|
|
89
|
+
→ the `SUMR_MODEL_*` env override → the adapter default.
|
|
64
90
|
|
|
65
91
|
## Native Channel Props
|
|
66
92
|
|
|
@@ -204,6 +230,10 @@ claude:
|
|
|
204
230
|
|
|
205
231
|
## Lifecycle File Fields
|
|
206
232
|
|
|
233
|
+
Create a lifecycle doc when the user asks for hooks, AI session automation, startup context, stop/closeout quality checks, pre-tool policy checks, post-tool formatters, or automated guardrails in Claude/Codex/Cursor/Copilot/Gemini/OpenCode.
|
|
234
|
+
|
|
235
|
+
Canonical source belongs in `{{PLAYBOOK_PATH}}/lifecycle/<name>.lc.md` for repo-wide behavior. Use tool-native hook files only as generated output.
|
|
236
|
+
|
|
207
237
|
For `category: lifecycle` files, one additional field is required:
|
|
208
238
|
|
|
209
239
|
| Field | Purpose | Example values |
|
|
@@ -221,17 +251,20 @@ Optional fields for lifecycle automations:
|
|
|
221
251
|
```yaml
|
|
222
252
|
---
|
|
223
253
|
category: lifecycle
|
|
224
|
-
name:
|
|
225
|
-
title:
|
|
226
|
-
description: "
|
|
227
|
-
event:
|
|
228
|
-
timeout:
|
|
229
|
-
statusMessage:
|
|
254
|
+
name: code-quality-closeout
|
|
255
|
+
title: Code Quality Closeout
|
|
256
|
+
description: "Runs changed-scope quality checks when an AI coding session stops."
|
|
257
|
+
event: Stop
|
|
258
|
+
timeout: 300
|
|
259
|
+
statusMessage: "Running code quality closeout"
|
|
260
|
+
target: code_quality_closeout.py
|
|
230
261
|
---
|
|
231
262
|
```
|
|
232
263
|
|
|
233
264
|
The body must contain a code-fenced script block (Python, Bash, or JS). The fence language determines the interpreter. Existing `category: hook` and `.hk.md` files still work as legacy aliases.
|
|
234
265
|
|
|
266
|
+
After authoring a lifecycle doc, run `sumr playbook validate --source docs`, then `sumr playbook sync --source docs --dry-run --json`, then normal sync once the preview shows only expected generated hook outputs.
|
|
267
|
+
|
|
235
268
|
## Tags (Optional)
|
|
236
269
|
|
|
237
270
|
`tags` is freeform and used only for human scanning — not parsed by the playbook sync. Keep them lowercase and concise.
|
|
@@ -0,0 +1,110 @@
|
|
|
1
|
+
---
|
|
2
|
+
category: reference
|
|
3
|
+
name: lifecycle-hooks
|
|
4
|
+
title: Lifecycle Hooks
|
|
5
|
+
description: "Lifecycle automation authoring for Claude and Codex hooks generated from Playbook docs. Use when users ask for hooks, AI automation, startup context, or tool-use guardrails."
|
|
6
|
+
label: Lifecycle Hooks
|
|
7
|
+
when: Creating hooks, AI lifecycle automations, startup context loaders, stop checks, pre-tool guards, post-tool checks, Claude hooks, or Codex hooks
|
|
8
|
+
order: 35
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
Create lifecycle source docs before editing tool-native hook files.
|
|
12
|
+
|
|
13
|
+
```text
|
|
14
|
+
User asks for hook/automation
|
|
15
|
+
-> create {{PLAYBOOK_PATH}}/lifecycle/<name>.lc.md
|
|
16
|
+
-> validate
|
|
17
|
+
-> dry-run sync
|
|
18
|
+
-> sync generated Claude/Codex hook outputs
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
## Language
|
|
22
|
+
|
|
23
|
+
- Say **lifecycle automation** in canonical Playbook docs.
|
|
24
|
+
- Treat **hook** as the generated AI Channel mechanism.
|
|
25
|
+
- `category: hook` and `.hk.md` are legacy aliases; use `category: lifecycle`
|
|
26
|
+
and `.lc.md` for new docs.
|
|
27
|
+
|
|
28
|
+
## Placement
|
|
29
|
+
|
|
30
|
+
- Use `{{PLAYBOOK_PATH}}/lifecycle/` for repo-wide AI session behavior.
|
|
31
|
+
- Place domain-specific lifecycle docs beside the domain they guard only when the
|
|
32
|
+
automation is inseparable from that domain.
|
|
33
|
+
- Keep lifecycle docs separate from normal standards unless the automation is
|
|
34
|
+
the whole point of the doc.
|
|
35
|
+
|
|
36
|
+
## Required frontmatter
|
|
37
|
+
|
|
38
|
+
```yaml
|
|
39
|
+
---
|
|
40
|
+
category: lifecycle
|
|
41
|
+
name: quality-stop-check
|
|
42
|
+
title: Quality Stop Check
|
|
43
|
+
description: "Runs a quality check before the AI session stops. Use when guarding handoff quality."
|
|
44
|
+
event: Stop
|
|
45
|
+
target: quality-stop-check.sh
|
|
46
|
+
---
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
Required:
|
|
50
|
+
|
|
51
|
+
- `category: lifecycle`
|
|
52
|
+
- `name`
|
|
53
|
+
- `title`
|
|
54
|
+
- `description`
|
|
55
|
+
- `event`
|
|
56
|
+
- `target`
|
|
57
|
+
|
|
58
|
+
Useful optional fields:
|
|
59
|
+
|
|
60
|
+
- `matcher` — event source or tool filter, such as `Bash|apply_patch`
|
|
61
|
+
- `timeout` — timeout in seconds
|
|
62
|
+
- `statusMessage` — short status shown while the hook runs
|
|
63
|
+
|
|
64
|
+
## Generated outputs
|
|
65
|
+
|
|
66
|
+
Claude and Codex both have generated hook outputs.
|
|
67
|
+
|
|
68
|
+
| Channel | Generated outputs |
|
|
69
|
+
|---|---|
|
|
70
|
+
| Claude | `.claude/hooks/sumr-*`, `.claude/settings.json` hook bindings |
|
|
71
|
+
| Codex | `.codex/hooks/sumr-*`, `.codex/hooks.json`, `.codex/config.toml` hooks feature flag |
|
|
72
|
+
|
|
73
|
+
Do not hand-edit generated hook outputs when a Playbook lifecycle source doc can
|
|
74
|
+
generate them. Edit the lifecycle source doc, validate, then sync.
|
|
75
|
+
|
|
76
|
+
## Script body
|
|
77
|
+
|
|
78
|
+
The lifecycle doc body must include one recognized code fence:
|
|
79
|
+
|
|
80
|
+
- `bash`
|
|
81
|
+
- `sh`
|
|
82
|
+
- `python`
|
|
83
|
+
- `js`
|
|
84
|
+
- `ts`
|
|
85
|
+
|
|
86
|
+
Example:
|
|
87
|
+
|
|
88
|
+
```markdown
|
|
89
|
+
\`\`\`bash
|
|
90
|
+
#!/usr/bin/env bash
|
|
91
|
+
set -euo pipefail
|
|
92
|
+
bun run check
|
|
93
|
+
\`\`\`
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
The renderer writes the script into the channel-specific hooks folder and binds
|
|
97
|
+
it to the configured lifecycle event.
|
|
98
|
+
|
|
99
|
+
## Validation flow
|
|
100
|
+
|
|
101
|
+
After creating or changing a lifecycle doc:
|
|
102
|
+
|
|
103
|
+
```bash
|
|
104
|
+
sumr playbook validate --source docs
|
|
105
|
+
sumr playbook sync --source docs --dry-run --json
|
|
106
|
+
sumr playbook sync --source docs
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
Review the dry-run output before writing. Expected changes should be limited to
|
|
110
|
+
generated hook scripts, hook binding files, and channel config files.
|
|
@@ -1,18 +1,30 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: playbook-authoring
|
|
3
3
|
title: Playbook Authoring
|
|
4
|
-
description: "How to write canonical SUMR Playbook docs: frontmatter schema, references, extraction markers, and authoring checklist. Use when creating or editing
|
|
5
|
-
tags: [authoring, docs, markdown]
|
|
4
|
+
description: "How to write canonical SUMR Playbook docs: frontmatter schema, references, extraction markers, and authoring checklist. Use when creating or editing Markdown docs, technical docs, AI docs, agent skills, specs, runbooks, or Playbook sources."
|
|
5
|
+
tags: [authoring, docs, markdown, ai-docs, technical-docs, specs, skills]
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
## When to Use
|
|
9
9
|
|
|
10
10
|
- Creating a new `.md` file anywhere under `{{PLAYBOOK_PATH}}/`.
|
|
11
11
|
- Editing or restructuring existing docs.
|
|
12
|
+
- Writing or reviewing technical docs, engineering docs, architecture docs, runbooks, specs, ADRs, standards, or process docs.
|
|
13
|
+
- Writing AI-facing docs, agent instructions, AI skills, agent skills, Codex/Claude resources, or Markdown files meant to guide an AI tool.
|
|
12
14
|
- Reviewing a doc for schema or structure compliance.
|
|
15
|
+
- Checking whether a Markdown file should be treated as Playbook format before editing it.
|
|
13
16
|
- Deciding whether to split a long doc into main + references.
|
|
14
17
|
- Explaining workflow, lifecycle, approval, or handoff flows.
|
|
15
18
|
|
|
19
|
+
If the user asks for "AI docs", "AI format", "agent docs", "agent skills",
|
|
20
|
+
"technical docs", "Markdown docs", "MD files", "spec files", "runbooks",
|
|
21
|
+
"ADRs", "standards", or "docs structure", treat this skill as relevant even
|
|
22
|
+
when the user never says "Playbook".
|
|
23
|
+
|
|
24
|
+
When modifying any `.md` file that is not clearly a generated artifact, ask
|
|
25
|
+
whether it should follow Playbook format unless the repository already requires
|
|
26
|
+
Playbook frontmatter for that folder.
|
|
27
|
+
|
|
16
28
|
## Core Principle: Layered Docs
|
|
17
29
|
|
|
18
30
|
Keep main docs concise and high-signal. Push deep detail into `category: reference` files in the same folder.
|
|
@@ -25,6 +37,17 @@ Keep main docs concise and high-signal. Push deep detail into `category: referen
|
|
|
25
37
|
|
|
26
38
|
Reference files attach automatically by **folder proximity** — no linking field needed. The main doc and its references live in the same folder.
|
|
27
39
|
|
|
40
|
+
## Lifecycle-First Hook Guidance
|
|
41
|
+
|
|
42
|
+
When a user asks for hooks, post-edit checks, AI session automation, quality
|
|
43
|
+
gates, startup context loading, tool-use guards, or any process that should run
|
|
44
|
+
automatically inside an AI tool, create a `category: lifecycle` Playbook doc
|
|
45
|
+
first. Treat Claude/Codex hook files as generated AI Channel outputs, not the
|
|
46
|
+
source of truth.
|
|
47
|
+
|
|
48
|
+
See **Lifecycle Hooks** for event fields, generated Claude and Codex outputs,
|
|
49
|
+
placement rules, and validation flow.
|
|
50
|
+
|
|
28
51
|
## Splitting Existing Docs
|
|
29
52
|
|
|
30
53
|
Before splitting a file, decide the owning context folder. Do not just create another peer `.md` file in a broad folder when the split content is really its own topic.
|
|
@@ -3,10 +3,8 @@ category: team-member
|
|
|
3
3
|
name: playbook-technical-writer
|
|
4
4
|
title: Playbook Technical Writer
|
|
5
5
|
description: "A SUMR Playbook authoring specialist. Use when drafting, reviewing, or restructuring canonical Playbook Markdown and AI resource docs."
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
codex:
|
|
9
|
-
sandbox_mode: read-only
|
|
6
|
+
modelTier: reasoning
|
|
7
|
+
access: read-only
|
|
10
8
|
---
|
|
11
9
|
|
|
12
10
|
# Playbook Technical Writer
|
|
@@ -24,6 +22,8 @@ Apply **playbook-authoring** before writing or editing Playbook docs.
|
|
|
24
22
|
- Review every fenced code block before extraction. Wrap dedicated examples, samples, and templates with `<!-- extract:examples -->`; keep short core snippets, file trees, and marker syntax examples inline.
|
|
25
23
|
- Keep frontmatter complete, stable, and tool-agnostic.
|
|
26
24
|
- Use `category: team-member`, `workflow`, or `lifecycle` only when the doc represents an AI resource rather than a normal skill/topic. Treat `hook` as a legacy alias for `lifecycle`.
|
|
25
|
+
- When the user asks for hooks, automatic AI checks, session start/stop behavior, pre/post tool guards, quality closeout, or similar AI-tool automation, propose a `category: lifecycle` doc in `{{PLAYBOOK_PATH}}/lifecycle/` before any tool-native hook edits.
|
|
26
|
+
- Explain that Claude/Codex hook files are generated AI Channel output; the Playbook lifecycle doc is the source of truth.
|
|
27
27
|
- Avoid editing generated channel output directly.
|
|
28
28
|
|
|
29
29
|
## Output
|
|
@@ -3,7 +3,7 @@ kind: CliModule
|
|
|
3
3
|
metadata:
|
|
4
4
|
name: playbook
|
|
5
5
|
package: "@sumrco/cli"
|
|
6
|
-
description: Sync
|
|
6
|
+
description: Sync Playbook docs into AI tools (Claude, Cursor, Codex, VS Code)
|
|
7
7
|
owners:
|
|
8
8
|
- team: "@sumr-org/playbook-team"
|
|
9
9
|
tags:
|
|
@@ -11,7 +11,7 @@ metadata:
|
|
|
11
11
|
- authoring
|
|
12
12
|
- ai-tools
|
|
13
13
|
spec:
|
|
14
|
-
visibility:
|
|
14
|
+
visibility: public
|
|
15
15
|
group: modules
|
|
16
16
|
targets:
|
|
17
17
|
contractVersion: ^1.0.0
|
|
@@ -19,25 +19,25 @@ spec:
|
|
|
19
19
|
commands:
|
|
20
20
|
- name: config
|
|
21
21
|
summary: Manage playbook configuration in sumr.yaml
|
|
22
|
-
visibility:
|
|
22
|
+
visibility: public
|
|
23
23
|
- name: sync
|
|
24
24
|
summary: Render Playbook Markdown into AI tool channels
|
|
25
|
-
visibility:
|
|
25
|
+
visibility: public
|
|
26
26
|
- name: validate
|
|
27
27
|
summary: Check Playbook docs for errors without writing files
|
|
28
|
-
visibility:
|
|
28
|
+
visibility: public
|
|
29
29
|
- name: status
|
|
30
30
|
summary: Show Playbook status, sources, and counts
|
|
31
|
-
visibility:
|
|
31
|
+
visibility: public
|
|
32
32
|
- name: add
|
|
33
33
|
summary: Scaffold a new Playbook doc with correct frontmatter
|
|
34
|
-
visibility:
|
|
34
|
+
visibility: public
|
|
35
35
|
- name: clean
|
|
36
36
|
summary: Remove all rendered Playbook outputs from this repo
|
|
37
|
-
visibility:
|
|
37
|
+
visibility: public
|
|
38
38
|
- name: authoring
|
|
39
39
|
summary: Print the canonical Playbook Markdown authoring contract
|
|
40
|
-
visibility:
|
|
40
|
+
visibility: public
|
|
41
41
|
exports:
|
|
42
42
|
resources:
|
|
43
43
|
- ./resources
|