claude-dev-env 1.4.0 → 1.8.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/agents/deep-research.md +170 -0
- package/bin/install.mjs +98 -26
- package/hooks/HOOK_SPECS_PROMPT_WORKFLOW.md +68 -0
- package/hooks/blocking/agent-execution-intent-gate.py +83 -0
- package/hooks/blocking/prompt-workflow-stop-guard.py +131 -0
- package/hooks/blocking/prompt_workflow_gate_core.py +161 -0
- package/hooks/blocking/test_agent_execution_intent_gate.py +106 -0
- package/hooks/blocking/test_context_control_policy_files.py +27 -0
- package/hooks/blocking/test_prompt_workflow_gate_core.py +68 -0
- package/hooks/blocking/test_prompt_workflow_stop_guard.py +144 -0
- package/hooks/hooks.json +10 -20
- package/package.json +3 -2
- package/rules/prompt-workflow-context-controls.md +48 -0
- package/skills/agent-prompt/SKILL.md +107 -9
- package/skills/deep-research/SKILL.md +80 -0
- package/skills/dream/SKILL.md +118 -0
- package/skills/prompt-generator/REFINEMENT_PIPELINE_RUNBOOK.md +174 -0
- package/skills/prompt-generator/SKILL.md +191 -12
- package/skills/research-mode/SKILL.md +53 -0
- package/skills/session-log/SKILL.md +237 -0
- package/skills/session-tidy/SKILL.md +181 -0
- package/skills/skill-writer/REFERENCE.md +160 -122
- package/skills/skill-writer/SKILL.md +131 -197
- package/LICENSE +0 -21
- package/README.md +0 -247
|
@@ -9,8 +9,8 @@ description: >-
|
|
|
9
9
|
agent delegation with prompt quality.
|
|
10
10
|
---
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
12
|
+
@packages/claude-dev-env/skills/prompt-generator/SKILL.md
|
|
13
|
+
@packages/claude-dev-env/skills/prompt-generator/REFERENCE.md
|
|
14
14
|
|
|
15
15
|
# Agent Prompt
|
|
16
16
|
|
|
@@ -20,7 +20,9 @@ The prompt-generator skill above defines the prompt-crafting workflow. This skil
|
|
|
20
20
|
|
|
21
21
|
## When this skill applies
|
|
22
22
|
|
|
23
|
-
Trigger when the user wants to delegate a task
|
|
23
|
+
Trigger only when the user explicitly wants to delegate or execute a task with an agent.
|
|
24
|
+
|
|
25
|
+
`/prompt-generator` is the default owner for prompt authoring and refinement. This skill starts after explicit execution intent.
|
|
24
26
|
|
|
25
27
|
When invoked with arguments (e.g. `/agent-prompt fix the auth bug via TDD`), treat the arguments as the task to build a prompt for and execute.
|
|
26
28
|
|
|
@@ -30,13 +32,13 @@ When invoked with arguments (e.g. `/agent-prompt fix the auth bug via TDD`), tre
|
|
|
30
32
|
|
|
31
33
|
Follow the prompt-generator workflow steps 1 through 8 exactly as written. Classify the prompt type, set degree of freedom, collect missing facts, build the prompt with XML tags and role, control format and style, add examples if needed, and self-check against the rubric.
|
|
32
34
|
|
|
33
|
-
|
|
35
|
+
After steps 1-8, continue directly to step 9 for context gathering; deliverables are handled through the orchestration flow below.
|
|
34
36
|
|
|
35
37
|
### Step 9: Gather context before crafting
|
|
36
38
|
|
|
37
39
|
The agent starts with zero conversation history. Before building the prompt, use Read, Glob, Grep, and other research tools to gather the concrete values the agent will need -- file paths, function signatures, existing patterns, branch names. Embed these directly in the prompt instead of telling the agent to "find" them.
|
|
38
40
|
|
|
39
|
-
The agent-spawn-protocol rule requires this: if any context question has the answer "I don't know", investigate first
|
|
41
|
+
The agent-spawn-protocol rule requires this: if any context question has the answer "I don't know", investigate first, then delegate with complete context.
|
|
40
42
|
|
|
41
43
|
Proactive context gathering enables agents to plan effectively from the start. Anthropic's emotion concepts research (2026) found that agents produce higher-quality output when they understand constraints, available tools, and system boundaries upfront — they incorporate these into their approach naturally, leading to better first attempts and more accurate results.
|
|
42
44
|
|
|
@@ -55,9 +57,46 @@ Always set `run_in_background: true`.
|
|
|
55
57
|
|
|
56
58
|
Generate a descriptive `name` (3-5 words, kebab-case) so the user can track progress and send follow-up messages via `SendMessage({to: name})`.
|
|
57
59
|
|
|
58
|
-
### Step
|
|
60
|
+
### Step 10A: Section-refinement orchestration mode (default for execution tasks)
|
|
61
|
+
|
|
62
|
+
Execution behavior: run this deterministic orchestration for delegated prompt work after explicit launch intent.
|
|
63
|
+
Prompt authoring and prompt refinement ownership remain in `/prompt-generator`.
|
|
64
|
+
|
|
65
|
+
Use simplified mode when either condition is true:
|
|
66
|
+
- The user explicitly requests single-agent execution
|
|
67
|
+
- The task is genuinely too small for orchestration (for example, one quick read/search)
|
|
68
|
+
|
|
69
|
+
This mode is triggered when execution input includes `pipeline_mode: internal_section_refinement_with_final_audit` or equivalent execution-ready orchestration metadata.
|
|
70
|
+
If present, carry forward the scope block (`target_local_roots`, `target_canonical_roots`, `target_file_globs`, `comparison_basis`, `completion_boundary`) so execution remains artifact-bound.
|
|
71
|
+
Execution launch payload must include `execution_intent: explicit`.
|
|
72
|
+
|
|
73
|
+
1. Spawn exactly 6 refinement agents, one per section in fixed order:
|
|
74
|
+
- `role`
|
|
75
|
+
- `context`
|
|
76
|
+
- `instructions`
|
|
77
|
+
- `constraints`
|
|
78
|
+
- `output_format`
|
|
79
|
+
- `examples`
|
|
80
|
+
2. Enforce section-only scope in each sub-prompt:
|
|
81
|
+
- "Edit `<SECTION_NAME>` and preserve all other sections unchanged."
|
|
82
|
+
3. Require section output contract from each agent:
|
|
83
|
+
- `improved_block`
|
|
84
|
+
- `rationale`
|
|
85
|
+
- `concise_diff`
|
|
86
|
+
4. Merge outputs into one canonical prompt after all 6 refiners finish.
|
|
87
|
+
5. Run one final audit agent against the merged prompt and checklist.
|
|
88
|
+
6. If audit fails, apply targeted fixes and re-run audit with capped retries (`max_retries: 2` unless user overrides).
|
|
59
89
|
|
|
60
|
-
|
|
90
|
+
Run all stages in this exact order.
|
|
91
|
+
|
|
92
|
+
### Step 11: Present for approval (must reflect default orchestration)
|
|
93
|
+
|
|
94
|
+
Use AskUserQuestion with one question. The question text must summarize:
|
|
95
|
+
- agent config (type, mode, name)
|
|
96
|
+
- orchestration mode (`section_refinement_with_final_audit` by default)
|
|
97
|
+
- retry cap for audit loop
|
|
98
|
+
|
|
99
|
+
Each option should use the `preview` field to show the full crafted prompt.
|
|
61
100
|
|
|
62
101
|
Options:
|
|
63
102
|
1. "Launch it" (recommended) -- preview shows the crafted prompt
|
|
@@ -77,10 +116,12 @@ On **"Cancel"**: acknowledge and stop.
|
|
|
77
116
|
When building the prompt in step 4, these adjustments ensure the agent can work independently:
|
|
78
117
|
|
|
79
118
|
**Context completeness** -- include file paths, line numbers, function names, branch state, and anything you learned during step 9. The agent cannot see this conversation.
|
|
119
|
+
Bind execution steps to the scope block artifacts passed from refinement output whenever available.
|
|
120
|
+
Keep runtime context compact: include only actionable facts required for execution.
|
|
80
121
|
|
|
81
122
|
**Acceptance criteria** -- state what "done" looks like. For code: include the test command. For research: specify the output format and save location.
|
|
82
123
|
|
|
83
|
-
**Scope boundary** -- include "
|
|
124
|
+
**Scope boundary** -- include "Make requested changes and keep surrounding code stable" or equivalent. Agents with explicit scope constraints stay aligned to task intent.
|
|
84
125
|
|
|
85
126
|
**Constraints from this project** -- if the project has CODE_RULES.md, TDD requirements, or naming conventions, include the relevant subset in the prompt so the agent follows them.
|
|
86
127
|
|
|
@@ -92,11 +133,68 @@ When building the prompt in step 4, these adjustments ensure the agent can work
|
|
|
92
133
|
|
|
93
134
|
**Temp file cleanup** -- If the agent may create scratch files during iteration, include cleanup instructions. Anthropic: "If you create any temporary new files, scripts, or helper files for iteration, clean up these files by removing them at the end of the task."
|
|
94
135
|
|
|
136
|
+
## Final audit-agent stage requirements (for default section-refinement mode)
|
|
137
|
+
|
|
138
|
+
After merge, run one dedicated audit agent that validates the full prompt against:
|
|
139
|
+
|
|
140
|
+
- Prompt-generator rubric requirements (`packages/claude-dev-env/skills/prompt-generator/SKILL.md`)
|
|
141
|
+
- The deterministic checklist from the handoff artifact
|
|
142
|
+
- Embedded research-mode evidence constraints below
|
|
143
|
+
|
|
144
|
+
Required audit output shape:
|
|
145
|
+
|
|
146
|
+
```json
|
|
147
|
+
{
|
|
148
|
+
"overall_status": "pass|fail",
|
|
149
|
+
"checklist_results": [
|
|
150
|
+
{
|
|
151
|
+
"check_id": "structured_scoped_instructions",
|
|
152
|
+
"status": "pass|fail",
|
|
153
|
+
"evidence_quote": "word-for-word quote",
|
|
154
|
+
"source_ref": "path-or-url",
|
|
155
|
+
"fix_if_fail": "targeted correction"
|
|
156
|
+
}
|
|
157
|
+
],
|
|
158
|
+
"corrective_edits": ["..."],
|
|
159
|
+
"retry_count": 0
|
|
160
|
+
}
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
### Embedded research-mode policy text (audit behavior)
|
|
164
|
+
|
|
165
|
+
The audit agent must enforce these constraints as policy text in the audit prompt (do not rely on a global mode switch):
|
|
166
|
+
|
|
167
|
+
- "Every recommendation, claim, or piece of advice must cite a specific source."
|
|
168
|
+
- "Ground your response in word-for-word quotes, not paraphrased summaries."
|
|
169
|
+
- "If you don't have a credible source for a claim, say 'I don't know'."
|
|
170
|
+
- Source priority:
|
|
171
|
+
1. Official vendor/creator docs for external tools
|
|
172
|
+
2. Local project files for local behavior
|
|
173
|
+
3. Academic or named expert sources
|
|
174
|
+
4. Reputable external sources with URLs
|
|
175
|
+
5. Blogs/community posts (lowest)
|
|
176
|
+
|
|
177
|
+
Policy source: `packages/claude-dev-env/skills/prompt-generator/REFINEMENT_PIPELINE_RUNBOOK.md`
|
|
178
|
+
|
|
179
|
+
## Section-refinement acceptance criteria
|
|
180
|
+
|
|
181
|
+
Section-refinement orchestration is done only when all are true:
|
|
182
|
+
|
|
183
|
+
- All 6 section agents ran, each scoped to exactly one section
|
|
184
|
+
- Merge produced one canonical prompt containing all six sections
|
|
185
|
+
- Final audit returned `overall_status: pass`
|
|
186
|
+
- Any non-pass audit was resolved through targeted revisions within retry cap
|
|
187
|
+
- AskUserQuestion approval gate was honored before launch
|
|
188
|
+
- Final user artifact includes one complete pasteable prompt block
|
|
189
|
+
|
|
95
190
|
## Constraints
|
|
96
191
|
|
|
97
|
-
-
|
|
192
|
+
- Present every launch for approval via AskUserQuestion before spawning
|
|
98
193
|
- Always run agents in background
|
|
99
194
|
- Gather context before crafting -- do not send an agent in blind
|
|
195
|
+
- Start only after explicit user execution intent; keep prompt authoring/refinement in `/prompt-generator`
|
|
196
|
+
- Default to `section_refinement_with_final_audit` orchestration for execution tasks unless user requests simplified mode
|
|
197
|
+
- Include `execution_intent: explicit` in Task/Agent launch prompts so runtime hooks can enforce deterministic gating
|
|
100
198
|
- If the task is too small for an agent (single file read, quick grep), say so and just do it directly
|
|
101
199
|
- Include obstacle handling: "When encountering obstacles, do not use destructive actions as a shortcut (e.g. --no-verify, discarding unfamiliar files)" -- agents without this guidance may take irreversible shortcuts
|
|
102
200
|
- Frame agent tasks with collaborative language and include permission to express uncertainty — agents produce higher-quality output with collaborative briefing (Anthropic emotion concepts research, 2026)
|
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: deep-research
|
|
3
|
+
description: "Deep Research mode — iterative multi-source research producing comprehensive Obsidian reports with citations. Official-docs-first methodology. Triggers: '/deep-research [topic]'"
|
|
4
|
+
argument-hint: "TOPIC or RESEARCH QUESTION"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Deep Research
|
|
8
|
+
|
|
9
|
+
You orchestrate a two-phase deep research pipeline. Phase 1 happens here (main thread). Phase 2 is delegated to the `deep-research` agent.
|
|
10
|
+
|
|
11
|
+
## Phase 1: Build the Research Prompt (Interactive Q&A)
|
|
12
|
+
|
|
13
|
+
The user's raw topic is: `$ARGUMENTS`
|
|
14
|
+
|
|
15
|
+
Your job is to turn this raw topic into a precise, well-scoped research brief using prompt-generator methodology. Follow these steps:
|
|
16
|
+
|
|
17
|
+
### Step 1: Classify and assess
|
|
18
|
+
|
|
19
|
+
Silently determine:
|
|
20
|
+
- **Complexity**: Is this a narrow factual question or a broad landscape survey?
|
|
21
|
+
- **Ambiguity**: Can you research this as-is, or does it need scoping?
|
|
22
|
+
- **Official docs**: Does this topic have official vendor/creator documentation? If yes, that is the primary source and must be consulted first.
|
|
23
|
+
|
|
24
|
+
### Step 2: Ask clarifying questions
|
|
25
|
+
|
|
26
|
+
Use AskUserQuestion to ask 1-3 questions. Choose from these dimensions based on what's genuinely unclear — skip any that are obvious from context:
|
|
27
|
+
|
|
28
|
+
- **Audience**: "Who is this research for?" (options: technical deep-dive, executive summary, personal learning, decision support)
|
|
29
|
+
- **Scope**: "Should I focus on a specific angle or survey the full landscape?" (options: specific angle with description field, broad survey, compare specific alternatives)
|
|
30
|
+
- **Recency**: "How important is recency?" (options: last 6 months only, last 1-2 years, historical overview, doesn't matter)
|
|
31
|
+
- **Depth**: "How deep should this go?" (options: quick overview 5-10 sources, standard 15-20 sources, exhaustive 25+ sources)
|
|
32
|
+
|
|
33
|
+
Skip clarification entirely only if the topic is already narrow, unambiguous, and the audience is obvious.
|
|
34
|
+
|
|
35
|
+
### Step 3: Construct the research brief
|
|
36
|
+
|
|
37
|
+
From the user's answers, write a structured research brief:
|
|
38
|
+
|
|
39
|
+
```
|
|
40
|
+
<research_brief>
|
|
41
|
+
<topic>The original topic, cleaned up</topic>
|
|
42
|
+
<official_docs>Known official documentation sources, or "none identified" if the topic lacks vendor docs</official_docs>
|
|
43
|
+
<scope>Exactly what to research — boundaries, inclusions, exclusions</scope>
|
|
44
|
+
<audience>Who this is for and what they need</audience>
|
|
45
|
+
<depth>Target source count and iteration budget</depth>
|
|
46
|
+
<output>What the final deliverable looks like</output>
|
|
47
|
+
<key_questions>
|
|
48
|
+
1. Specific question the research must answer
|
|
49
|
+
2. Another specific question
|
|
50
|
+
3. ...
|
|
51
|
+
</key_questions>
|
|
52
|
+
</research_brief>
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
Show the brief to the user. Ask: "Does this capture what you need, or should I adjust the scope?"
|
|
56
|
+
|
|
57
|
+
### Step 4: Set iteration budget
|
|
58
|
+
|
|
59
|
+
Map the user's depth preference to iteration count:
|
|
60
|
+
- Quick overview: 8 iterations
|
|
61
|
+
- Standard (default): 15 iterations
|
|
62
|
+
- Exhaustive: 25 iterations
|
|
63
|
+
|
|
64
|
+
## Phase 2: Launch the Research Agent
|
|
65
|
+
|
|
66
|
+
Once the brief is confirmed, spawn the `deep-research` agent using the Agent tool with:
|
|
67
|
+
|
|
68
|
+
- **subagent_type**: `deep-research`
|
|
69
|
+
- **prompt**: The full `<research_brief>` XML block from Step 3, plus the iteration budget
|
|
70
|
+
- **mode**: `bypassPermissions` (research agent needs unrestricted tool access for web searches)
|
|
71
|
+
- **description**: "Deep research: [short topic summary]"
|
|
72
|
+
|
|
73
|
+
The agent handles everything from here: iteration, state tracking, and Obsidian output.
|
|
74
|
+
|
|
75
|
+
When the agent returns, summarize:
|
|
76
|
+
1. Where the report was saved (Obsidian path)
|
|
77
|
+
2. How many sources were consulted (official vs secondary)
|
|
78
|
+
3. Any gaps or limitations noted
|
|
79
|
+
|
|
80
|
+
Then clean up temporary files: `.deep-research-state.md`
|
|
@@ -0,0 +1,118 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: dream
|
|
3
|
+
description: Consolidate, prune, and reorganize auto memory files. Simulates Auto Dream -- fixes format drift, deduplicates facts, enforces index structure. Use when memory feels stale or cluttered. Triggers on '/dream', 'consolidate memory', 'clean up memory', 'dream'.
|
|
4
|
+
disable-model-invocation: true
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Dream: Memory Consolidation
|
|
8
|
+
|
|
9
|
+
## Overview
|
|
10
|
+
|
|
11
|
+
Consolidate auto memory by enforcing the format contract, pruning stale content, deduplicating facts, and rebuilding MEMORY.md as a clean index.
|
|
12
|
+
|
|
13
|
+
**Announce at start:** "Running memory consolidation (dream)."
|
|
14
|
+
|
|
15
|
+
**Context:** Standalone maintenance utility. Run periodically or when memory feels cluttered. Simulates the Auto Dream feature that is in gradual rollout.
|
|
16
|
+
|
|
17
|
+
## The Format Contract
|
|
18
|
+
|
|
19
|
+
Source: Claude Code client system prompt + [official docs](https://code.claude.com/docs/en/memory).
|
|
20
|
+
|
|
21
|
+
**MEMORY.md is an index, not a memory.** It should contain only one-line pointers to topic files:
|
|
22
|
+
- Format: `- [Title](file.md) -- one-line hook`
|
|
23
|
+
- Target: under ~150 characters per entry
|
|
24
|
+
- Hard limit: 200 lines / 25KB (only this much loads at session start)
|
|
25
|
+
- No content, tables, or multi-line facts directly in MEMORY.md
|
|
26
|
+
|
|
27
|
+
**Topic files require frontmatter:**
|
|
28
|
+
```yaml
|
|
29
|
+
---
|
|
30
|
+
name: {{topic name}}
|
|
31
|
+
description: {{one-line description}}
|
|
32
|
+
type: {{user | feedback | project | reference}}
|
|
33
|
+
---
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
**Organization:** Semantic by topic, not chronological by session.
|
|
37
|
+
|
|
38
|
+
## The Process
|
|
39
|
+
|
|
40
|
+
### Phase 1: Audit
|
|
41
|
+
|
|
42
|
+
Read MEMORY.md and every file in the memory directory. For each file, check:
|
|
43
|
+
|
|
44
|
+
1. **Frontmatter present?** Must have name, description, type fields.
|
|
45
|
+
2. **Type correct?** Must be one of: user, feedback, project, reference.
|
|
46
|
+
3. **Named by topic?** Files named `session-YYYY-MM-DD-*` should be renamed to their actual topic.
|
|
47
|
+
|
|
48
|
+
For MEMORY.md, check:
|
|
49
|
+
1. **Index entries only?** Flag any line that is NOT a `- [Title](file.md)` link or a `##` section header.
|
|
50
|
+
2. **Content leaking into index?** Flag inline facts, tables, multi-line bullet points.
|
|
51
|
+
3. **Under 200 lines?** Flag if approaching the limit.
|
|
52
|
+
|
|
53
|
+
### Phase 2: Propose Changes
|
|
54
|
+
|
|
55
|
+
Present a structured report to the user with these sections:
|
|
56
|
+
|
|
57
|
+
**Format violations** -- files missing frontmatter, content in MEMORY.md
|
|
58
|
+
**Stale content** -- items older than 14 days with forward-looking TODOs or "Next/Pending" sections that may be completed
|
|
59
|
+
**Duplicates** -- facts that appear in both topic files and MEMORY.md inline, or across multiple topic files
|
|
60
|
+
**Rename candidates** -- session-dated files that should be topic-named
|
|
61
|
+
**Proposed actions** -- numbered list of specific changes (extract, merge, prune, rename, add frontmatter)
|
|
62
|
+
|
|
63
|
+
Do NOT execute any changes yet. Wait for user approval.
|
|
64
|
+
|
|
65
|
+
### Phase 3: Execute
|
|
66
|
+
|
|
67
|
+
After user approves (all or selected items):
|
|
68
|
+
|
|
69
|
+
1. **Extract** inline MEMORY.md content into new or existing topic files with proper frontmatter.
|
|
70
|
+
2. **Add frontmatter** to files that lack it.
|
|
71
|
+
3. **Rename** session-dated files to topic names.
|
|
72
|
+
4. **Deduplicate** by removing redundant copies (keep the most complete version).
|
|
73
|
+
5. **Prune** stale forward-looking content (TODOs, "Next" sections) from old files.
|
|
74
|
+
6. **Rebuild MEMORY.md** as a clean index -- one-line entries only, grouped by `##` section headers.
|
|
75
|
+
|
|
76
|
+
### Phase 4: Verify
|
|
77
|
+
|
|
78
|
+
After execution, read the rebuilt MEMORY.md and confirm:
|
|
79
|
+
- Every entry is a one-line link
|
|
80
|
+
- Every referenced file exists and has valid frontmatter
|
|
81
|
+
- No orphaned files (files in directory but not in index)
|
|
82
|
+
- Total line count under 200
|
|
83
|
+
|
|
84
|
+
Report the results: files changed, lines saved, violations fixed.
|
|
85
|
+
|
|
86
|
+
## Output Format
|
|
87
|
+
|
|
88
|
+
Phase 2 report structure:
|
|
89
|
+
|
|
90
|
+
```
|
|
91
|
+
## Dream Report
|
|
92
|
+
|
|
93
|
+
### Format Violations (X found)
|
|
94
|
+
- [file] -- [issue]
|
|
95
|
+
|
|
96
|
+
### Stale Content (X flagged)
|
|
97
|
+
- [file] -- [what's stale] -- [age]
|
|
98
|
+
|
|
99
|
+
### Duplicates (X found)
|
|
100
|
+
- [fact] -- appears in [file1] and [file2]
|
|
101
|
+
|
|
102
|
+
### Proposed Actions
|
|
103
|
+
1. [action] -- [file] -- [reason]
|
|
104
|
+
2. ...
|
|
105
|
+
|
|
106
|
+
Approve all, select by number, or cancel?
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
## After Completion
|
|
110
|
+
|
|
111
|
+
Report summary: files modified, created, renamed, deleted. Line count before/after.
|
|
112
|
+
|
|
113
|
+
## Best Practices
|
|
114
|
+
|
|
115
|
+
- Run after long sessions or when starting fresh on a project
|
|
116
|
+
- Check stale flags manually -- dream cannot verify if TODOs were completed without reading the actual codebase
|
|
117
|
+
- The 14-day staleness threshold is a heuristic, not a hard rule
|
|
118
|
+
- When in doubt about whether to prune, flag it for the user rather than proposing deletion
|
|
@@ -0,0 +1,174 @@
|
|
|
1
|
+
# Prompt Refinement Pipeline Runbook
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Validate deterministic behavior for:
|
|
6
|
+
|
|
7
|
+
1. Base prompt generation (`/prompt-generator`)
|
|
8
|
+
2. Six section refiners (owned by `/prompt-generator`)
|
|
9
|
+
3. Merge + final audit with citation-grounded checks
|
|
10
|
+
4. Targeted fix + capped re-audit loop
|
|
11
|
+
|
|
12
|
+
## Sample Input
|
|
13
|
+
|
|
14
|
+
Use this command:
|
|
15
|
+
|
|
16
|
+
```text
|
|
17
|
+
/prompt-generator Create a trusted final system prompt for a coding agent that edits files safely, follows user scope, and returns concise status updates.
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
## Expected Stage Artifacts
|
|
21
|
+
|
|
22
|
+
1. **Base stage**
|
|
23
|
+
- Scope block is present and explicit:
|
|
24
|
+
- `target_local_roots`
|
|
25
|
+
- `target_canonical_roots` (if applicable)
|
|
26
|
+
- `target_file_globs`
|
|
27
|
+
- `comparison_basis`
|
|
28
|
+
- `completion_boundary`
|
|
29
|
+
- XML scaffold includes all sections:
|
|
30
|
+
- `<role>`
|
|
31
|
+
- `<context>`
|
|
32
|
+
- `<instructions>`
|
|
33
|
+
- `<constraints>`
|
|
34
|
+
- `<output_format>`
|
|
35
|
+
- `<examples>`
|
|
36
|
+
- Includes internal refinement object with:
|
|
37
|
+
- `pipeline_mode: internal_section_refinement_with_final_audit`
|
|
38
|
+
- `required_sections` list with all six sections
|
|
39
|
+
- section/merge/audit output contracts
|
|
40
|
+
|
|
41
|
+
2. **Section refinement stage**
|
|
42
|
+
- Exactly 6 agent runs, one per section.
|
|
43
|
+
- Each section output includes:
|
|
44
|
+
- `improved_block`
|
|
45
|
+
- `rationale`
|
|
46
|
+
- `concise_diff`
|
|
47
|
+
- No section agent edits another section.
|
|
48
|
+
|
|
49
|
+
3. **Merge stage**
|
|
50
|
+
- One canonical merged prompt with all six sections.
|
|
51
|
+
|
|
52
|
+
4. **Audit stage**
|
|
53
|
+
- Output includes:
|
|
54
|
+
- `overall_status`
|
|
55
|
+
- `checklist_results`
|
|
56
|
+
- `corrective_edits`
|
|
57
|
+
- `retry_count`
|
|
58
|
+
- Every checklist item includes:
|
|
59
|
+
- `status`
|
|
60
|
+
- `evidence_quote` (direct quote)
|
|
61
|
+
- `source_ref`
|
|
62
|
+
- `fix_if_fail`
|
|
63
|
+
|
|
64
|
+
5. **Final output**
|
|
65
|
+
- One complete prompt block that is copy-pasteable.
|
|
66
|
+
- Internal refinement object is not shown unless debug output was requested.
|
|
67
|
+
- Default output must not leak the raw internal refinement object fields.
|
|
68
|
+
|
|
69
|
+
## Deterministic Checklist Coverage
|
|
70
|
+
|
|
71
|
+
Audit report must include all check IDs:
|
|
72
|
+
|
|
73
|
+
- `structured_scoped_instructions`
|
|
74
|
+
- `sequential_steps_present`
|
|
75
|
+
- `positive_framing`
|
|
76
|
+
- `acceptance_criteria_defined`
|
|
77
|
+
- `safety_reversibility_language`
|
|
78
|
+
- `no_destructive_shortcuts_guidance`
|
|
79
|
+
- `concrete_output_contract`
|
|
80
|
+
- `scope_boundary_present`
|
|
81
|
+
- `explicit_scope_anchors_present`
|
|
82
|
+
- `all_instructions_artifact_bound`
|
|
83
|
+
- `no_ambiguous_scope_terms`
|
|
84
|
+
- `completion_boundary_measurable`
|
|
85
|
+
- `citation_grounding_policy_present`
|
|
86
|
+
- `source_priority_rules_present`
|
|
87
|
+
|
|
88
|
+
## Citation and Grounding Validation
|
|
89
|
+
|
|
90
|
+
For each factual compliance claim in the audit:
|
|
91
|
+
|
|
92
|
+
- Include a source citation
|
|
93
|
+
- Include a word-for-word quote
|
|
94
|
+
- If unsupported, explicitly return "I don't know"
|
|
95
|
+
|
|
96
|
+
Source priority must be applied in this order:
|
|
97
|
+
|
|
98
|
+
1. Official vendor docs (external behavior)
|
|
99
|
+
2. Local project files (local behavior)
|
|
100
|
+
3. Academic / named experts
|
|
101
|
+
4. Reputable external URLs
|
|
102
|
+
5. Blog/community content
|
|
103
|
+
|
|
104
|
+
## Non-pass Loop Validation
|
|
105
|
+
|
|
106
|
+
If `overall_status` is `fail`:
|
|
107
|
+
|
|
108
|
+
1. Apply only targeted edits listed in `corrective_edits`
|
|
109
|
+
2. Re-run audit
|
|
110
|
+
3. Stop after retry cap (`max_retries: 2` unless explicitly overridden)
|
|
111
|
+
4. Return unresolved failures with evidence if still failing at cap
|
|
112
|
+
|
|
113
|
+
## Ownership and Execution-Intent Validation
|
|
114
|
+
|
|
115
|
+
- Prompt refinement remains inside `/prompt-generator`.
|
|
116
|
+
- `/agent-prompt` is used only after explicit execution/delegation intent.
|
|
117
|
+
- Execution launch metadata includes `execution_intent: explicit`.
|
|
118
|
+
- Final refined prompt content is treated as artifact text during refinement and audit.
|
|
119
|
+
- Execution steps (when requested) are bound to scope block artifacts.
|
|
120
|
+
|
|
121
|
+
## Scope-Phrasing Validation
|
|
122
|
+
|
|
123
|
+
- Reject ambiguous scope wording such as "this session", "current files", "here", "above", or "as needed" when used as scope boundaries.
|
|
124
|
+
- Require artifact-bound replacements using explicit roots, globs, comparison basis, and measurable completion boundary.
|
|
125
|
+
|
|
126
|
+
## Runtime Hook Gate Validation
|
|
127
|
+
|
|
128
|
+
Validate fail-closed runtime gates:
|
|
129
|
+
|
|
130
|
+
1. **Execution-intent gate (PreToolUse Task/Agent)**
|
|
131
|
+
- Deny execution when `execution_intent: explicit` marker is missing.
|
|
132
|
+
- Deny execution when required scope anchors are missing from launch payload.
|
|
133
|
+
2. **Stop leakage/scope/checklist gate**
|
|
134
|
+
- Block responses that leak raw internal refinement object fields unless debug intent is explicit.
|
|
135
|
+
- Block responses missing deterministic checklist rows when audit output is present.
|
|
136
|
+
- Block responses using ambiguous scope phrasing in scope-bound sections.
|
|
137
|
+
|
|
138
|
+
## Context-Footprint Controls
|
|
139
|
+
|
|
140
|
+
- Keep baseline prompt-workflow policy minimal by default.
|
|
141
|
+
- Store stable enforcement text in hooks/rules; avoid repeating full policy blocks in prompt artifacts.
|
|
142
|
+
- Load heavy skills on demand based on explicit task intent.
|
|
143
|
+
- Prefer canonical references and compact outputs over repeated long policy text.
|
|
144
|
+
|
|
145
|
+
## Deterministic vs Semantic Boundary
|
|
146
|
+
|
|
147
|
+
- **Deterministic (fail-closed):**
|
|
148
|
+
- Missing execution intent marker
|
|
149
|
+
- Missing required scope anchors
|
|
150
|
+
- Raw internal object leakage without debug intent
|
|
151
|
+
- Missing required checklist rows in audit output
|
|
152
|
+
- Ambiguous scope terms in scope-bound text
|
|
153
|
+
- **Semantic-only (auditor layer):**
|
|
154
|
+
- Overall quality/readability of scope wording beyond banned-term checks
|
|
155
|
+
- Whether instruction binding quality is "good enough" beyond explicit anchor presence
|
|
156
|
+
- Whether context compaction is optimal for a specific task
|
|
157
|
+
|
|
158
|
+
## Doc Alignment Validation
|
|
159
|
+
|
|
160
|
+
Each major workflow requirement added in skills text must map to at least one principle:
|
|
161
|
+
|
|
162
|
+
- Structured/scoped instructions
|
|
163
|
+
- Clear sequential process
|
|
164
|
+
- Positive framing
|
|
165
|
+
- Explicit acceptance criteria
|
|
166
|
+
- Concrete output format contract
|
|
167
|
+
- Reversibility/safety constraints
|
|
168
|
+
|
|
169
|
+
## Traceability Validation
|
|
170
|
+
|
|
171
|
+
Each major requirement in skill text should point to:
|
|
172
|
+
|
|
173
|
+
- Anthropic best-practice URL, and/or
|
|
174
|
+
- Local source file path used as authority
|