@leeovery/claude-technical-workflows 2.1.31 → 2.1.32
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 +36 -5
- package/hooks/workflows/compact-recovery.sh +81 -0
- package/hooks/workflows/session-cleanup.sh +26 -0
- package/hooks/workflows/session-env.sh +17 -0
- package/hooks/workflows/system-check.sh +100 -0
- package/hooks/workflows/write-session-state.sh +66 -0
- package/package.json +1 -1
- package/skills/begin-implementation/SKILL.md +158 -0
- package/skills/begin-planning/SKILL.md +87 -0
- package/skills/continue-feature/SKILL.md +177 -0
- package/skills/continue-feature/references/detect-phase.md +92 -0
- package/skills/continue-feature/references/invoke-implementation.md +43 -0
- package/skills/continue-feature/references/invoke-planning.md +43 -0
- package/skills/continue-feature/references/invoke-specification.md +55 -0
- package/skills/continue-feature/references/phase-bridge.md +58 -0
- package/skills/continue-feature/scripts/discovery.sh +216 -0
- package/skills/link-dependencies/SKILL.md +6 -0
- package/skills/start-discussion/SKILL.md +22 -1
- package/skills/start-feature/SKILL.md +100 -38
- package/skills/start-feature/references/gather-feature-context.md +60 -0
- package/skills/start-feature/references/invoke-discussion.md +24 -0
- package/skills/start-feature/references/phase-bridge.md +37 -0
- package/skills/start-implementation/SKILL.md +22 -1
- package/skills/start-planning/SKILL.md +22 -1
- package/skills/start-research/SKILL.md +23 -1
- package/skills/start-review/SKILL.md +22 -1
- package/skills/start-specification/SKILL.md +8 -2
- package/skills/start-specification/references/handoffs/continue-concluded.md +15 -0
- package/skills/start-specification/references/handoffs/continue.md +15 -0
- package/skills/start-specification/references/handoffs/create-with-incorporation.md +15 -0
- package/skills/start-specification/references/handoffs/create.md +15 -0
- package/skills/start-specification/references/handoffs/unify-with-incorporation.md +15 -0
- package/skills/start-specification/references/handoffs/unify.md +15 -0
- package/skills/status/SKILL.md +7 -1
- package/skills/technical-planning/references/author-tasks.md +2 -0
- package/skills/technical-planning/references/output-formats/tick/about.md +5 -0
- package/skills/technical-planning/references/output-formats/tick/authoring.md +11 -0
- package/skills/technical-planning/references/output-formats/tick/updating.md +2 -0
- package/skills/technical-planning/references/plan-construction.md +3 -8
- package/skills/technical-planning/references/plan-index-schema.md +4 -3
- package/skills/view-plan/SKILL.md +6 -0
package/README.md
CHANGED
|
@@ -64,8 +64,8 @@ Pick your entry point based on where you are:
|
|
|
64
64
|
- **Know what you're building?** → Start with `/start-discussion`
|
|
65
65
|
You've moved past exploration and want to capture architecture decisions, edge cases, and rationale for specific topics.
|
|
66
66
|
|
|
67
|
-
- **Clear feature, ready to
|
|
68
|
-
You
|
|
67
|
+
- **Clear feature, ready to build?** → Use `/start-feature`
|
|
68
|
+
You know what you're building. Start-feature gathers context, creates a discussion, then pipelines through specification → planning → implementation automatically via plan mode bridges.
|
|
69
69
|
|
|
70
70
|
**Why research is the recommended default:** When you move from research to discussion, the discussion skill analyses your research document and automatically breaks it into focused discussion topics. Skip research and you manage topic structure yourself.
|
|
71
71
|
|
|
@@ -121,10 +121,35 @@ Not every task needs the full workflow. These skills gather inputs flexibly and
|
|
|
121
121
|
| `/start-feature` | Create a spec directly from inline context (skip research/discussion) |
|
|
122
122
|
| `/link-dependencies` | Wire cross-topic dependencies across plans |
|
|
123
123
|
|
|
124
|
+
### Feature Pipeline
|
|
125
|
+
|
|
126
|
+
`/start-feature` chains the full workflow into an automated pipeline:
|
|
127
|
+
|
|
128
|
+
```
|
|
129
|
+
/start-feature
|
|
130
|
+
│
|
|
131
|
+
▼
|
|
132
|
+
Discussion ──▶ Specification ──▶ Planning ──▶ Implementation
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
**How it works:** After each phase completes, a plan mode bridge clears context and advances to the next phase automatically. You approve each transition with "clear context and continue" — this keeps each phase in a clean context window.
|
|
136
|
+
|
|
137
|
+
If a session is interrupted, run `/continue-feature` to pick up where you left off. It reads artifact state to determine the next phase.
|
|
138
|
+
|
|
124
139
|
### Under the Hood
|
|
125
140
|
|
|
126
141
|
Skills are organised in two tiers. **Entry-point skills** (`/start-*`, `/status`, etc.) gather context from files, prompts, or inline input. **Processing skills** (`technical-*`) receive those inputs and do the work — they don't know or care where inputs came from. This separation means the same processing skill can be invoked from different entry points: `/start-specification` and `/start-feature` both feed `technical-specification` with different inputs. You can create custom entry-point skills that feed processing skills in new ways.
|
|
127
142
|
|
|
143
|
+
### Compaction Recovery
|
|
144
|
+
|
|
145
|
+
Long-running skills can hit context compaction, where Claude's conversation is summarized and procedural detail is lost. The hook system provides automatic recovery:
|
|
146
|
+
|
|
147
|
+
- **Project-level hooks** installed in `.claude/settings.json` persist through compaction events
|
|
148
|
+
- On compaction, the recovery hook reads session state from disk and injects authoritative context — the skill to re-read, the artifact to resume, and pipeline instructions
|
|
149
|
+
- On first run, a bootstrap hook detects missing configuration and installs it automatically (requires one Claude restart)
|
|
150
|
+
|
|
151
|
+
Session state is ephemeral (gitignored, cleaned up on session end) and per-session — multiple concurrent sessions don't interfere.
|
|
152
|
+
|
|
128
153
|
### Workflow Skills
|
|
129
154
|
|
|
130
155
|
| Phase | Skill |
|
|
@@ -226,7 +251,8 @@ skills/
|
|
|
226
251
|
│
|
|
227
252
|
├── # Entry-point skills (user-invocable)
|
|
228
253
|
├── migrate/ # Keep workflow files in sync with system design
|
|
229
|
-
├── start-feature/ #
|
|
254
|
+
├── start-feature/ # Pipeline: discussion → spec → plan → impl
|
|
255
|
+
├── continue-feature/ # Pipeline: route feature to next phase
|
|
230
256
|
├── link-dependencies/ # Standalone: wire cross-topic deps
|
|
231
257
|
├── start-research/ # Begin research
|
|
232
258
|
├── start-discussion/ # Begin discussions
|
|
@@ -235,7 +261,11 @@ skills/
|
|
|
235
261
|
├── start-implementation/ # Begin implementation
|
|
236
262
|
├── start-review/ # Begin review
|
|
237
263
|
├── status/ # Show workflow status
|
|
238
|
-
|
|
264
|
+
├── view-plan/ # View plan tasks
|
|
265
|
+
│
|
|
266
|
+
├── # Bridge skills (model-invocable — pipeline pre-flight)
|
|
267
|
+
├── begin-planning/ # Pre-flight for planning in pipeline
|
|
268
|
+
└── begin-implementation/ # Pre-flight for implementation in pipeline
|
|
239
269
|
|
|
240
270
|
agents/
|
|
241
271
|
├── review-task-verifier.md # Verifies single task implementation for review
|
|
@@ -298,7 +328,8 @@ Independent skills that gather inputs flexibly (inline context, files, or prompt
|
|
|
298
328
|
|
|
299
329
|
| Skill | Description |
|
|
300
330
|
|---------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
301
|
-
| [**/start-feature**](skills/start-feature/) |
|
|
331
|
+
| [**/start-feature**](skills/start-feature/) | Start a new feature through the full pipeline. Gathers context, creates a discussion, then bridges through specification → planning → implementation. |
|
|
332
|
+
| [**/continue-feature**](skills/continue-feature/) | Continue a feature through its next pipeline phase. Routes automatically based on artifact state. Used manually or from plan mode bridges. |
|
|
302
333
|
| [**/link-dependencies**](skills/link-dependencies/) | Link external dependencies across topics. Scans plans and wires up unresolved cross-topic dependencies. |
|
|
303
334
|
|
|
304
335
|
### Creating Custom Skills
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
#
|
|
3
|
+
# compact-recovery.sh
|
|
4
|
+
#
|
|
5
|
+
# SessionStart hook (compact).
|
|
6
|
+
# Reads session_id from stdin, looks for saved session state,
|
|
7
|
+
# and injects recovery context so the model can resume work.
|
|
8
|
+
#
|
|
9
|
+
|
|
10
|
+
# Resolve project directory
|
|
11
|
+
PROJECT_DIR="${CLAUDE_PROJECT_DIR:-}"
|
|
12
|
+
if [ -z "$PROJECT_DIR" ]; then
|
|
13
|
+
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
|
14
|
+
PROJECT_DIR="$(cd "$SCRIPT_DIR/../../.." && pwd)"
|
|
15
|
+
fi
|
|
16
|
+
|
|
17
|
+
# Extract session_id from stdin JSON
|
|
18
|
+
session_id=$(cat | grep -o '"session_id" *: *"[^"]*"' | sed 's/.*: *"//;s/"//')
|
|
19
|
+
|
|
20
|
+
if [ -z "$session_id" ]; then
|
|
21
|
+
exit 0
|
|
22
|
+
fi
|
|
23
|
+
|
|
24
|
+
SESSION_FILE="$PROJECT_DIR/docs/workflow/.cache/sessions/${session_id}.yaml"
|
|
25
|
+
|
|
26
|
+
if [ ! -f "$SESSION_FILE" ]; then
|
|
27
|
+
exit 0
|
|
28
|
+
fi
|
|
29
|
+
|
|
30
|
+
# Parse YAML fields (simple key: value format)
|
|
31
|
+
topic=$(grep '^topic:' "$SESSION_FILE" | awk '{print $2}')
|
|
32
|
+
skill=$(grep '^skill:' "$SESSION_FILE" | awk '{print $2}')
|
|
33
|
+
artifact=$(grep '^artifact:' "$SESSION_FILE" | awk '{print $2}')
|
|
34
|
+
|
|
35
|
+
# Check for pipeline section
|
|
36
|
+
has_pipeline=false
|
|
37
|
+
if grep -q '^pipeline:' "$SESSION_FILE"; then
|
|
38
|
+
has_pipeline=true
|
|
39
|
+
# Extract after_conclude content (indented block after "after_conclude: |")
|
|
40
|
+
pipeline_content=$(awk '
|
|
41
|
+
/^ after_conclude:/ { capture=1; next }
|
|
42
|
+
capture && /^[^ ]/ { exit }
|
|
43
|
+
capture && /^ / { sub(/^ /, ""); print }
|
|
44
|
+
' "$SESSION_FILE")
|
|
45
|
+
fi
|
|
46
|
+
|
|
47
|
+
# Build additionalContext
|
|
48
|
+
context="CONTEXT COMPACTION — SESSION RECOVERY
|
|
49
|
+
|
|
50
|
+
Context was just compacted. Follow these instructions carefully.
|
|
51
|
+
|
|
52
|
+
─── IMMEDIATE: Resume current work ───
|
|
53
|
+
$([ -n "$topic" ] && echo "
|
|
54
|
+
You are working on topic '${topic}'.")
|
|
55
|
+
Skill: ${skill}
|
|
56
|
+
|
|
57
|
+
1. Re-read that skill file completely
|
|
58
|
+
2. Follow its 'Resuming After Context Refresh' section
|
|
59
|
+
3. Re-read the artifact: ${artifact}
|
|
60
|
+
4. Continue working until the skill reaches its natural conclusion
|
|
61
|
+
|
|
62
|
+
The files on disk are authoritative — not the conversation summary."
|
|
63
|
+
|
|
64
|
+
if [ "$has_pipeline" = true ] && [ -n "$pipeline_content" ]; then
|
|
65
|
+
context="${context}
|
|
66
|
+
|
|
67
|
+
─── AFTER CONCLUSION ONLY ───
|
|
68
|
+
|
|
69
|
+
${pipeline_content}
|
|
70
|
+
|
|
71
|
+
Do NOT enter plan mode or invoke continue-feature until the current
|
|
72
|
+
phase is complete. Finish the current phase first."
|
|
73
|
+
fi
|
|
74
|
+
|
|
75
|
+
# Escape context for JSON output
|
|
76
|
+
json_context=$(printf '%s' "$context" | sed 's/\\/\\\\/g; s/"/\\"/g; s/$/\\n/' | tr -d '\n')
|
|
77
|
+
json_context="\"${json_context%\\n}\""
|
|
78
|
+
|
|
79
|
+
echo "{ \"hookSpecificOutput\": { \"hookEventName\": \"SessionStart\", \"additionalContext\": ${json_context} } }"
|
|
80
|
+
|
|
81
|
+
exit 0
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
#
|
|
3
|
+
# session-cleanup.sh
|
|
4
|
+
#
|
|
5
|
+
# SessionEnd hook.
|
|
6
|
+
# Reads session_id from stdin JSON and removes the session state file if it exists.
|
|
7
|
+
#
|
|
8
|
+
|
|
9
|
+
# Resolve project directory
|
|
10
|
+
PROJECT_DIR="${CLAUDE_PROJECT_DIR:-}"
|
|
11
|
+
if [ -z "$PROJECT_DIR" ]; then
|
|
12
|
+
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
|
13
|
+
PROJECT_DIR="$(cd "$SCRIPT_DIR/../../.." && pwd)"
|
|
14
|
+
fi
|
|
15
|
+
|
|
16
|
+
# Extract session_id from stdin JSON
|
|
17
|
+
session_id=$(cat | grep -o '"session_id" *: *"[^"]*"' | sed 's/.*: *"//;s/"//')
|
|
18
|
+
|
|
19
|
+
if [ -n "$session_id" ]; then
|
|
20
|
+
session_file="$PROJECT_DIR/docs/workflow/.cache/sessions/${session_id}.yaml"
|
|
21
|
+
if [ -f "$session_file" ]; then
|
|
22
|
+
rm -f "$session_file"
|
|
23
|
+
fi
|
|
24
|
+
fi
|
|
25
|
+
|
|
26
|
+
exit 0
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
#
|
|
3
|
+
# session-env.sh
|
|
4
|
+
#
|
|
5
|
+
# SessionStart hook (startup|resume|clear).
|
|
6
|
+
# Reads session_id from stdin JSON and writes it to CLAUDE_ENV_FILE
|
|
7
|
+
# so entry-point skills can reference the session ID.
|
|
8
|
+
#
|
|
9
|
+
|
|
10
|
+
# Extract session_id from stdin JSON
|
|
11
|
+
session_id=$(cat | grep -o '"session_id" *: *"[^"]*"' | sed 's/.*: *"//;s/"//')
|
|
12
|
+
|
|
13
|
+
if [ -n "$session_id" ] && [ -n "$CLAUDE_ENV_FILE" ]; then
|
|
14
|
+
echo "export CLAUDE_SESSION_ID=${session_id}" > "$CLAUDE_ENV_FILE"
|
|
15
|
+
fi
|
|
16
|
+
|
|
17
|
+
exit 0
|
|
@@ -0,0 +1,100 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
#
|
|
3
|
+
# system-check.sh
|
|
4
|
+
#
|
|
5
|
+
# Bootstrap hook for workflow skills. Ensures project-level hooks
|
|
6
|
+
# (compaction recovery, session tracking) are installed in
|
|
7
|
+
# .claude/settings.json.
|
|
8
|
+
#
|
|
9
|
+
# Called as a PreToolUse hook from skill frontmatter.
|
|
10
|
+
# Uses jq if available, falls back to node, then to manual instructions.
|
|
11
|
+
#
|
|
12
|
+
|
|
13
|
+
# Consume stdin (PreToolUse sends JSON — must be drained)
|
|
14
|
+
cat > /dev/null 2>&1 || true
|
|
15
|
+
|
|
16
|
+
# Resolve project directory
|
|
17
|
+
PROJECT_DIR="${CLAUDE_PROJECT_DIR:-}"
|
|
18
|
+
if [ -z "$PROJECT_DIR" ]; then
|
|
19
|
+
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
|
20
|
+
PROJECT_DIR="$(cd "$SCRIPT_DIR/../../.." && pwd)"
|
|
21
|
+
fi
|
|
22
|
+
|
|
23
|
+
SETTINGS_FILE="$PROJECT_DIR/.claude/settings.json"
|
|
24
|
+
|
|
25
|
+
# ─── Detection (grep only) ───
|
|
26
|
+
|
|
27
|
+
has_our_hooks() {
|
|
28
|
+
[ -f "$SETTINGS_FILE" ] &&
|
|
29
|
+
grep -q "hooks/workflows/session-env.sh" "$SETTINGS_FILE" 2>/dev/null &&
|
|
30
|
+
grep -q "hooks/workflows/compact-recovery.sh" "$SETTINGS_FILE" 2>/dev/null &&
|
|
31
|
+
grep -q "hooks/workflows/session-cleanup.sh" "$SETTINGS_FILE" 2>/dev/null
|
|
32
|
+
}
|
|
33
|
+
|
|
34
|
+
if has_our_hooks; then
|
|
35
|
+
exit 0
|
|
36
|
+
fi
|
|
37
|
+
|
|
38
|
+
# ─── Hook JSON templates ───
|
|
39
|
+
# $CLAUDE_PROJECT_DIR below is intentionally literal (expanded by Claude Code at runtime)
|
|
40
|
+
# shellcheck disable=SC2016
|
|
41
|
+
HOOKS_ONLY='{
|
|
42
|
+
"hooks": {
|
|
43
|
+
"SessionStart": [
|
|
44
|
+
{
|
|
45
|
+
"matcher": "startup|resume|clear",
|
|
46
|
+
"hooks": [{ "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/workflows/session-env.sh" }]
|
|
47
|
+
},
|
|
48
|
+
{
|
|
49
|
+
"matcher": "compact",
|
|
50
|
+
"hooks": [{ "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/workflows/compact-recovery.sh" }]
|
|
51
|
+
}
|
|
52
|
+
],
|
|
53
|
+
"SessionEnd": [
|
|
54
|
+
{
|
|
55
|
+
"hooks": [{ "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/workflows/session-cleanup.sh" }]
|
|
56
|
+
}
|
|
57
|
+
]
|
|
58
|
+
}
|
|
59
|
+
}'
|
|
60
|
+
|
|
61
|
+
# ─── Installation ───
|
|
62
|
+
|
|
63
|
+
mkdir -p "$(dirname "$SETTINGS_FILE")"
|
|
64
|
+
|
|
65
|
+
if [ ! -f "$SETTINGS_FILE" ] || [ ! -s "$SETTINGS_FILE" ]; then
|
|
66
|
+
# No file or empty — write fresh
|
|
67
|
+
printf '%s\n' "$HOOKS_ONLY" > "$SETTINGS_FILE"
|
|
68
|
+
|
|
69
|
+
elif command -v jq >/dev/null 2>&1; then
|
|
70
|
+
# Merge using jq — append our entries to existing arrays
|
|
71
|
+
merged=$(jq \
|
|
72
|
+
--argjson ours "$HOOKS_ONLY" \
|
|
73
|
+
'
|
|
74
|
+
.hooks //= {} |
|
|
75
|
+
.hooks.SessionStart = ((.hooks.SessionStart // []) + $ours.hooks.SessionStart) |
|
|
76
|
+
.hooks.SessionEnd = ((.hooks.SessionEnd // []) + $ours.hooks.SessionEnd)
|
|
77
|
+
' "$SETTINGS_FILE")
|
|
78
|
+
printf '%s\n' "$merged" > "$SETTINGS_FILE"
|
|
79
|
+
|
|
80
|
+
elif command -v node >/dev/null 2>&1; then
|
|
81
|
+
# Merge using node
|
|
82
|
+
node -e "
|
|
83
|
+
const fs = require('fs');
|
|
84
|
+
const existing = JSON.parse(fs.readFileSync(process.argv[1], 'utf8'));
|
|
85
|
+
const ours = JSON.parse(process.argv[2]);
|
|
86
|
+
existing.hooks = existing.hooks || {};
|
|
87
|
+
existing.hooks.SessionStart = (existing.hooks.SessionStart || []).concat(ours.hooks.SessionStart);
|
|
88
|
+
existing.hooks.SessionEnd = (existing.hooks.SessionEnd || []).concat(ours.hooks.SessionEnd);
|
|
89
|
+
fs.writeFileSync(process.argv[1], JSON.stringify(existing, null, 2) + '\n');
|
|
90
|
+
" "$SETTINGS_FILE" "$HOOKS_ONLY"
|
|
91
|
+
|
|
92
|
+
else
|
|
93
|
+
# No tools available — write hooks to separate file with instructions
|
|
94
|
+
printf '%s\n' "$HOOKS_ONLY" > "${SETTINGS_FILE%.json}.workflow-hooks.json"
|
|
95
|
+
echo '{ "continue": false, "stopReason": "Your .claude/settings.json needs workflow hooks but neither jq nor node is available to merge automatically. The hooks have been written to .claude/settings.workflow-hooks.json — please merge the SessionStart and SessionEnd entries into your settings.json, then restart Claude Code." }'
|
|
96
|
+
exit 0
|
|
97
|
+
fi
|
|
98
|
+
|
|
99
|
+
echo '{ "continue": false, "stopReason": "Workflow hooks configured. Restart Claude Code to activate compaction recovery, then re-invoke your skill." }'
|
|
100
|
+
exit 0
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
#
|
|
3
|
+
# write-session-state.sh
|
|
4
|
+
#
|
|
5
|
+
# Helper script called by entry-point skills to save session state for
|
|
6
|
+
# compaction recovery.
|
|
7
|
+
#
|
|
8
|
+
# Usage:
|
|
9
|
+
# write-session-state.sh "<topic>" "<skill-path>" "<artifact-path>" [--pipeline "<after-conclude instructions>"]
|
|
10
|
+
#
|
|
11
|
+
# Requires CLAUDE_SESSION_ID in environment (set by session-env.sh).
|
|
12
|
+
#
|
|
13
|
+
|
|
14
|
+
# Resolve project directory
|
|
15
|
+
PROJECT_DIR="${CLAUDE_PROJECT_DIR:-}"
|
|
16
|
+
if [ -z "$PROJECT_DIR" ]; then
|
|
17
|
+
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
|
18
|
+
PROJECT_DIR="$(cd "$SCRIPT_DIR/../../.." && pwd)"
|
|
19
|
+
fi
|
|
20
|
+
|
|
21
|
+
if [ -z "$CLAUDE_SESSION_ID" ]; then
|
|
22
|
+
# No session ID available — silently skip
|
|
23
|
+
exit 0
|
|
24
|
+
fi
|
|
25
|
+
|
|
26
|
+
topic="$1"
|
|
27
|
+
skill="$2"
|
|
28
|
+
artifact="$3"
|
|
29
|
+
pipeline_content=""
|
|
30
|
+
|
|
31
|
+
# Parse optional --pipeline flag
|
|
32
|
+
shift 3 || true
|
|
33
|
+
while [ $# -gt 0 ]; do
|
|
34
|
+
case "$1" in
|
|
35
|
+
--pipeline)
|
|
36
|
+
pipeline_content="$2"
|
|
37
|
+
shift 2
|
|
38
|
+
;;
|
|
39
|
+
*)
|
|
40
|
+
shift
|
|
41
|
+
;;
|
|
42
|
+
esac
|
|
43
|
+
done
|
|
44
|
+
|
|
45
|
+
SESSIONS_DIR="$PROJECT_DIR/docs/workflow/.cache/sessions"
|
|
46
|
+
mkdir -p "$SESSIONS_DIR"
|
|
47
|
+
|
|
48
|
+
SESSION_FILE="$SESSIONS_DIR/${CLAUDE_SESSION_ID}.yaml"
|
|
49
|
+
|
|
50
|
+
# Write base fields
|
|
51
|
+
cat > "$SESSION_FILE" <<EOF
|
|
52
|
+
topic: ${topic}
|
|
53
|
+
skill: ${skill}
|
|
54
|
+
artifact: ${artifact}
|
|
55
|
+
EOF
|
|
56
|
+
|
|
57
|
+
# Append pipeline section if provided
|
|
58
|
+
if [ -n "$pipeline_content" ]; then
|
|
59
|
+
cat >> "$SESSION_FILE" <<EOF
|
|
60
|
+
pipeline:
|
|
61
|
+
after_conclude: |
|
|
62
|
+
$(echo "$pipeline_content" | sed 's/^/ /')
|
|
63
|
+
EOF
|
|
64
|
+
fi
|
|
65
|
+
|
|
66
|
+
exit 0
|
package/package.json
CHANGED
|
@@ -0,0 +1,158 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: begin-implementation
|
|
3
|
+
description: "Bridge skill for the feature pipeline. Runs pre-flight checks for implementation and invokes the technical-implementation skill. Called by continue-feature — not directly by users."
|
|
4
|
+
user-invocable: false
|
|
5
|
+
allowed-tools: Bash(.claude/skills/start-implementation/scripts/discovery.sh)
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
Invoke the **technical-implementation** skill for this conversation with pre-flight context.
|
|
9
|
+
|
|
10
|
+
> **⚠️ ZERO OUTPUT RULE**: Do not narrate your processing. Produce no output until a step or reference file explicitly specifies display content. No "proceeding with...", no discovery summaries, no routing decisions, no transition text. Your first output must be content explicitly called for by the instructions.
|
|
11
|
+
|
|
12
|
+
## Instructions
|
|
13
|
+
|
|
14
|
+
Follow these steps EXACTLY as written. Do not skip steps or combine them.
|
|
15
|
+
|
|
16
|
+
This skill is a **bridge** — it runs pre-flight checks for implementation and hands off to the processing skill. The topic has already been selected by the caller.
|
|
17
|
+
|
|
18
|
+
**CRITICAL**: This guidance is mandatory.
|
|
19
|
+
|
|
20
|
+
- After each user interaction, STOP and wait for their response before proceeding
|
|
21
|
+
- Never assume or anticipate user choices
|
|
22
|
+
- Complete each step fully before moving to the next
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## Step 1: Run Discovery
|
|
27
|
+
|
|
28
|
+
Execute the start-implementation discovery script to gather current state:
|
|
29
|
+
|
|
30
|
+
```bash
|
|
31
|
+
.claude/skills/start-implementation/scripts/discovery.sh
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Parse the output to find the plan matching the provided topic. Extract:
|
|
35
|
+
|
|
36
|
+
- **Plan details**: status, format, plan_id, specification, specification_exists
|
|
37
|
+
- **External dependencies**: external_deps, has_unresolved_deps
|
|
38
|
+
- **Dependency resolution**: deps_satisfied, deps_blocking
|
|
39
|
+
- **Implementation tracking**: from `implementation.files` matching the topic
|
|
40
|
+
- **Environment**: setup_file_exists, requires_setup
|
|
41
|
+
|
|
42
|
+
If the plan is missing or not concluded, this is an error — report it and stop.
|
|
43
|
+
|
|
44
|
+
→ Proceed to **Step 2**.
|
|
45
|
+
|
|
46
|
+
---
|
|
47
|
+
|
|
48
|
+
## Step 2: Check External Dependencies
|
|
49
|
+
|
|
50
|
+
Check the plan's `external_deps` and `dependency_resolution` from the discovery output.
|
|
51
|
+
|
|
52
|
+
#### If all deps satisfied (or no deps)
|
|
53
|
+
|
|
54
|
+
> *Output the next fenced block as a code block:*
|
|
55
|
+
|
|
56
|
+
```
|
|
57
|
+
External dependencies satisfied.
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
→ Proceed to **Step 3**.
|
|
61
|
+
|
|
62
|
+
#### If any deps are blocking
|
|
63
|
+
|
|
64
|
+
> *Output the next fenced block as a code block:*
|
|
65
|
+
|
|
66
|
+
```
|
|
67
|
+
Missing Dependencies
|
|
68
|
+
|
|
69
|
+
Unresolved (not yet planned):
|
|
70
|
+
• {topic}: {description}
|
|
71
|
+
No plan exists. Create with /start-planning or mark as
|
|
72
|
+
satisfied externally.
|
|
73
|
+
|
|
74
|
+
Incomplete (planned but not implemented):
|
|
75
|
+
• {topic}: {plan}:{task-id} not yet completed
|
|
76
|
+
This task must be completed first.
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
> *Output the next fenced block as markdown (not a code block):*
|
|
80
|
+
|
|
81
|
+
```
|
|
82
|
+
· · · · · · · · · · · ·
|
|
83
|
+
- **`i`/`implement`** — Implement the blocking dependencies first
|
|
84
|
+
- **`s`/`satisfied`** — Mark a dependency as satisfied externally
|
|
85
|
+
- **`c`/`continue`** — Continue anyway (at your own risk)
|
|
86
|
+
· · · · · · · · · · · ·
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
**STOP.** Wait for user response.
|
|
90
|
+
|
|
91
|
+
If the user chooses `implement`, end here — suggest running `/start-implementation` for the blocking topic. If `satisfied`, update the plan frontmatter (`state: satisfied_externally`) and continue. If `continue`, proceed.
|
|
92
|
+
|
|
93
|
+
→ Proceed to **Step 3**.
|
|
94
|
+
|
|
95
|
+
---
|
|
96
|
+
|
|
97
|
+
## Step 3: Check Environment Setup
|
|
98
|
+
|
|
99
|
+
Use the `environment` section from the discovery output:
|
|
100
|
+
|
|
101
|
+
**If `setup_file_exists: true` and `requires_setup: false`:**
|
|
102
|
+
|
|
103
|
+
> *Output the next fenced block as a code block:*
|
|
104
|
+
|
|
105
|
+
```
|
|
106
|
+
Environment: No special setup required.
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
→ Proceed to **Step 4**.
|
|
110
|
+
|
|
111
|
+
**If `setup_file_exists: true` and `requires_setup: true`:**
|
|
112
|
+
|
|
113
|
+
> *Output the next fenced block as a code block:*
|
|
114
|
+
|
|
115
|
+
```
|
|
116
|
+
Environment setup file found: docs/workflow/environment-setup.md
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
→ Proceed to **Step 4**.
|
|
120
|
+
|
|
121
|
+
**If `setup_file_exists: false` or `requires_setup: unknown`:**
|
|
122
|
+
|
|
123
|
+
> *Output the next fenced block as a code block:*
|
|
124
|
+
|
|
125
|
+
```
|
|
126
|
+
Are there any environment setup instructions I should follow before implementation?
|
|
127
|
+
(Or "none" if no special setup is needed)
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
**STOP.** Wait for user response.
|
|
131
|
+
|
|
132
|
+
- If the user provides instructions, save them to `docs/workflow/environment-setup.md`, commit
|
|
133
|
+
- If the user says no/none, create `docs/workflow/environment-setup.md` with "No special setup required." and commit
|
|
134
|
+
|
|
135
|
+
→ Proceed to **Step 4**.
|
|
136
|
+
|
|
137
|
+
---
|
|
138
|
+
|
|
139
|
+
## Step 4: Invoke the Skill
|
|
140
|
+
|
|
141
|
+
Determine the implementation tracking state:
|
|
142
|
+
- If a tracking file exists for this topic → use its status
|
|
143
|
+
- If no tracking file → status is "not-started"
|
|
144
|
+
|
|
145
|
+
Construct the handoff and invoke the [technical-implementation](../technical-implementation/SKILL.md) skill:
|
|
146
|
+
|
|
147
|
+
```
|
|
148
|
+
Implementation session for: {topic}
|
|
149
|
+
Plan: docs/workflow/planning/{topic}/plan.md
|
|
150
|
+
Format: {format}
|
|
151
|
+
Plan ID: {plan_id} (if applicable)
|
|
152
|
+
Specification: docs/workflow/specification/{topic}/specification.md (exists: {true|false})
|
|
153
|
+
Implementation tracking: {exists | new} (status: {status})
|
|
154
|
+
Dependencies: {All satisfied | notes}
|
|
155
|
+
Environment: {Setup required | No special setup required}
|
|
156
|
+
|
|
157
|
+
Invoke the technical-implementation skill.
|
|
158
|
+
```
|
|
@@ -0,0 +1,87 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: begin-planning
|
|
3
|
+
description: "Bridge skill for the feature pipeline. Runs pre-flight checks for planning and invokes the technical-planning skill. Called by continue-feature — not directly by users."
|
|
4
|
+
user-invocable: false
|
|
5
|
+
allowed-tools: Bash(.claude/skills/start-planning/scripts/discovery.sh)
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
Invoke the **technical-planning** skill for this conversation with pre-flight context.
|
|
9
|
+
|
|
10
|
+
> **⚠️ ZERO OUTPUT RULE**: Do not narrate your processing. Produce no output until a step or reference file explicitly specifies display content. No "proceeding with...", no discovery summaries, no routing decisions, no transition text. Your first output must be content explicitly called for by the instructions.
|
|
11
|
+
|
|
12
|
+
## Instructions
|
|
13
|
+
|
|
14
|
+
Follow these steps EXACTLY as written. Do not skip steps or combine them.
|
|
15
|
+
|
|
16
|
+
This skill is a **bridge** — it runs pre-flight checks for planning and hands off to the processing skill. The topic has already been selected by the caller.
|
|
17
|
+
|
|
18
|
+
**CRITICAL**: This guidance is mandatory.
|
|
19
|
+
|
|
20
|
+
- After each user interaction, STOP and wait for their response before proceeding
|
|
21
|
+
- Never assume or anticipate user choices
|
|
22
|
+
- Complete each step fully before moving to the next
|
|
23
|
+
|
|
24
|
+
---
|
|
25
|
+
|
|
26
|
+
## Step 1: Run Discovery
|
|
27
|
+
|
|
28
|
+
Execute the start-planning discovery script to gather current state:
|
|
29
|
+
|
|
30
|
+
```bash
|
|
31
|
+
.claude/skills/start-planning/scripts/discovery.sh
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Parse the output to extract:
|
|
35
|
+
|
|
36
|
+
- **Cross-cutting specifications** from `specifications.crosscutting` (name, status)
|
|
37
|
+
- **Common format** from `plans.common_format`
|
|
38
|
+
|
|
39
|
+
The topic was provided by the caller. Confirm the specification exists and is concluded:
|
|
40
|
+
|
|
41
|
+
- Check `specifications.feature` for the topic
|
|
42
|
+
- If the spec is missing or not concluded, this is an error — report it and stop
|
|
43
|
+
|
|
44
|
+
→ Proceed to **Step 2**.
|
|
45
|
+
|
|
46
|
+
---
|
|
47
|
+
|
|
48
|
+
## Step 2: Handle Cross-Cutting Context
|
|
49
|
+
|
|
50
|
+
Load **[cross-cutting-context.md](../start-planning/references/cross-cutting-context.md)** and follow its instructions as written.
|
|
51
|
+
|
|
52
|
+
→ Proceed to **Step 3**.
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## Step 3: Gather Additional Context
|
|
57
|
+
|
|
58
|
+
> *Output the next fenced block as markdown (not a code block):*
|
|
59
|
+
|
|
60
|
+
```
|
|
61
|
+
· · · · · · · · · · · ·
|
|
62
|
+
Any additional context for planning?
|
|
63
|
+
|
|
64
|
+
- **`c`/`continue`** — Continue with the specification as-is
|
|
65
|
+
- Or provide additional context (priorities, constraints, new considerations)
|
|
66
|
+
· · · · · · · · · · · ·
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
**STOP.** Wait for user response.
|
|
70
|
+
|
|
71
|
+
→ Proceed to **Step 4**.
|
|
72
|
+
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
## Step 4: Invoke the Skill
|
|
76
|
+
|
|
77
|
+
Construct the handoff and invoke the [technical-planning](../technical-planning/SKILL.md) skill:
|
|
78
|
+
|
|
79
|
+
```
|
|
80
|
+
Planning session for: {topic}
|
|
81
|
+
Specification: docs/workflow/specification/{topic}/specification.md
|
|
82
|
+
Additional context: {summary of user's answer from Step 3, or "none"}
|
|
83
|
+
Cross-cutting references: {list of applicable cross-cutting specs with brief summaries, or "none"}
|
|
84
|
+
Recommended output format: {common_format from discovery if non-empty, otherwise "none"}
|
|
85
|
+
|
|
86
|
+
Invoke the technical-planning skill.
|
|
87
|
+
```
|