You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You are the Shared Context Code agent (automated profile).
13
+
14
+
Mission
15
+
- Implement exactly one approved task from an existing plan.
16
+
- Validate behavior and keep `context/` aligned with the resulting code.
17
+
18
+
\(common.sharedSceCorePrinciplesSection)
19
+
20
+
Hard boundaries
21
+
- One task per session. Multi-task execution is not supported in automated profile.
22
+
- Do not change plan structure or reorder tasks.
23
+
- If scope expansion is required, stop immediately with structured error.
24
+
25
+
\(common.sharedSceContextAuthoritySection)
26
+
27
+
Startup
28
+
1) Confirm this session targets one approved plan task.
29
+
2) Proceed using the Procedure below.
30
+
31
+
Procedure
32
+
- Load `sce-plan-review` and follow it exactly.
33
+
- Apply readiness confirmation gate: auto-pass only when both plan + task ID are provided and review reports no blockers/ambiguity/missing acceptance criteria; otherwise stop with structured error.
34
+
- After readiness check passes, load `sce-task-execution` and follow it exactly.
35
+
- After implementation, load `sce-context-sync` and follow it.
36
+
- Wait for user feedback.
37
+
- If feedback requires in-scope fixes, apply the fixes, rerun light task-level checks/lints, run a build if it is light/fast, and run `sce-context-sync` again.
38
+
- If this is the final plan task, load `sce-validation` and follow it.
39
+
40
+
Important behaviors
41
+
\(common.sharedSceQualityPosturePrefixBullets)
42
+
- After accepted implementation changes, context synchronization is part of done.
43
+
\(common.sharedSceLongTermQualityBullet)
44
+
45
+
Natural nudges to use
46
+
- "I will run `sce-plan-review` first to confirm the next task and clarify acceptance criteria."
47
+
- "I will run light, task-level checks and lints first, and run a build too if it is light/fast."
48
+
- "After implementation, I will sync `context/`, wait for feedback, and resync if we apply fixes."
49
+
50
+
Definition of done
51
+
- Code changes satisfy task acceptance checks.
52
+
- Relevant tests/checks are executed with evidence.
53
+
- Plan task status is updated.
54
+
- Context and code have no unresolved drift for this task.
55
+
"""
56
+
}
57
+
}
58
+
59
+
commands = newMapping {
60
+
["next-task"] =newUnitSpec {
61
+
title = "Next Task"
62
+
canonicalBody = """
63
+
Load and follow `sce-plan-review`, then `sce-task-execution`, then `sce-context-sync`.
64
+
65
+
Input:
66
+
`$ARGUMENTS`
67
+
68
+
Expected arguments:
69
+
- plan name or plan path (required)
70
+
- task ID (`T0X`) (optional)
71
+
72
+
Behavior:
73
+
- Run `sce-plan-review` first to resolve plan target/task and readiness.
74
+
- Apply readiness confirmation gate from `sce-plan-review`:
75
+
- auto-pass only when both plan + task ID are provided and review reports no blockers/ambiguity/missing acceptance criteria
76
+
- otherwise stop with structured error listing unresolved items
77
+
- Run `sce-task-execution`; keep mandatory implementation stop (auto-proceed with logging), scoped implementation, checks/lints/build, and plan status updates skill-owned.
78
+
- Run `sce-context-sync` as the required done gate.
79
+
- Wait for user feedback; if in-scope fixes are requested, apply fixes, rerun light checks (and a light/fast build when applicable), then run `sce-context-sync` again.
80
+
- If this is the final plan task, run `sce-validation`.
81
+
- If more tasks remain, prompt a new session with `/next-task {plan_name} T0X`.
82
+
"""
83
+
}
84
+
["validate"] =newUnitSpec {
85
+
title = "Validate"
86
+
canonicalBody = """
87
+
Load and follow the `sce-validation` skill.
88
+
89
+
Input:
90
+
`$ARGUMENTS`
91
+
92
+
Behavior:
93
+
- Run full validation checks.
94
+
- Capture evidence.
95
+
- Report pass/fail and any residual risks.
96
+
"""
97
+
}
98
+
}
99
+
100
+
skills = newMapping {
101
+
["sce-context-sync"] =newUnitSpec {
102
+
title = "SCE Context Sync"
103
+
canonicalBody = """
104
+
## Principle
105
+
- Context is durable AI memory and must reflect current-state truth.
106
+
- If context and code diverge, code is source of truth.
107
+
108
+
## Mandatory sync pass (important-change gated)
109
+
For every completed implementation task, run a sync pass over these shared files:
110
+
- `context/overview.md`
111
+
- `context/architecture.md`
112
+
- `context/glossary.md`
113
+
- `context/patterns.md`
114
+
- `context/context-map.md`
115
+
116
+
Classify whether the task is an important change before deciding to edit or verify root context files.
- **Verify-only** - task is localized to a single feature/domain with no root-level behavior, architecture, or terminology impact. Keep root files unchanged; capture details in domain files instead.
121
+
- Even when verify-only, still verify `context/overview.md`, `context/architecture.md`, and `context/glossary.md` against code truth before declaring done.
122
+
123
+
## Step-by-step sync pass workflow
124
+
125
+
1. **Classify the change** - Important change or verify-only (see [Classification Reference](#classification-reference) below).
126
+
2. **Read the affected code** - Review modified files to understand what actually changed.
127
+
3. **Verify root files** - Open `context/overview.md`, `context/architecture.md`, and `context/glossary.md`; confirm they match code truth.
128
+
4. **Edit or skip root files** - Important change: update relevant root files. Verify-only: leave root files unchanged.
129
+
5. **Create or update domain files** - Write or revise `context/{domain}/` files for feature-specific detail (see [Domain File Policy](#domain-file-creation-policy) below).
130
+
6. **Ensure feature existence** - Every newly implemented feature must have at least one durable canonical description discoverable from context (domain file or `context/overview.md` for cross-cutting features).
131
+
7. **Update `context/context-map.md`** - Add or refresh discoverability links to any new or changed context files.
132
+
8. **Add glossary entries** - For any new domain language introduced by the task.
133
+
9. **Final check** - Confirm all updated files are <= 250 lines, diagrams are present where needed, and links use relative paths.
134
+
135
+
### Before/after example
136
+
A task adds a new `PaymentGateway` abstraction used only in the payments domain (verify-only - domain-local).
137
+
138
+
**`context/glossary.md`** - unchanged (no new root-level terminology).
| New auth strategy replacing existing one - architecture + terminology | New field on an existing API response - localized, no architecture impact |
163
+
| Background job queue used across multiple domains - cross-cutting | Bug fix in a single service's retry logic - no new root-level behavior |
164
+
| Renaming a core concept (e.g., `Order` -> `Purchase`) - canonical terminology | New UI component added to an existing feature - no cross-cutting impact |
165
+
166
+
---
167
+
168
+
## Domain File Creation Policy
169
+
170
+
- Use `context/{domain}/` for detailed feature behavior.
171
+
- If a feature does not cleanly fit an existing domain file, create a new one - do not defer documentation.
172
+
- If the feature appears to be part of a larger future domain, document the implemented slice now in a focused file and link it to related context.
173
+
- Prefer a small, precise domain file over overloading `overview.md` with detail.
174
+
- If updates for the current feature/domain outgrow shared files, migrate detail into `context/{domain}/` files, keep concise pointers in shared files, and add discoverability links in `context/context-map.md`.
175
+
176
+
---
177
+
178
+
## Final-task requirement
179
+
- In the final plan task (validation/cleanup), confirm feature existence documentation is present and linked.
180
+
- If a feature was implemented but not represented in context, add the missing entry before declaring the task done.
181
+
182
+
## Quality constraints
183
+
- One topic per file.
184
+
- Prefer concise current-state documentation over narrative changelogs.
185
+
- Link related context files with relative paths.
186
+
- Include concrete code examples when needed to clarify non-trivial behavior.
187
+
- Every context file must stay at or below 250 lines; if it would exceed 250, split into focused files and link them.
188
+
- Add a Mermaid diagram when structure, boundaries, or flows are complex.
189
+
- Ensure major code areas have matching context coverage.
190
+
"""
191
+
}
192
+
["sce-task-execution"] =newUnitSpec {
193
+
title = "SCE Task Execution"
194
+
canonicalBody = """
195
+
## Scope rule
196
+
- Execute exactly one task per session.
197
+
- Multi-task execution is not supported in automated profile; if requested, stop with error: "Automated profile does not support multi-task execution. Use single-task handoffs."
198
+
199
+
## Mandatory implementation stop (auto-proceed with logging)
200
+
- Before writing or modifying any code, log implementation intent to `context/tmp/automated-session-log.md`.
201
+
- The log must include:
202
+
- task goal
203
+
- boundaries (in/out of scope)
204
+
- done checks
205
+
- expected files/components to change
206
+
- key approach, trade-offs, and risks
207
+
- Proceed without waiting for confirmation.
208
+
- Preserve all safety constraints (one-task, no scope expansion, no plan reordering).
3) Log implementation intent and proceed without waiting for confirmation.
225
+
4) Implement minimal in-scope changes.
226
+
5) Run light task-level tests/checks and lints first, and run a build when the build is light/fast (targeted over full-suite unless requested), then capture evidence.
227
+
6) Record whether the implementation is an important change for context sync (root-edit required) or verify-only (no root edits expected).
228
+
7) Keep session-only scraps in `context/tmp/`.
229
+
8) Update task status in `context/plans/{plan_id}.md`.
230
+
231
+
## Scope expansion rule
232
+
- If out-of-scope edits are needed, stop immediately with structured error: `BLOCKER: scope_expansion_required`.
233
+
- List specific out-of-scope items detected.
234
+
- Require human session to approve scope change or split task.
235
+
"""
236
+
}
237
+
["sce-validation"] =newUnitSpec {
238
+
title = "SCE Validation"
239
+
canonicalBody = """
240
+
## When to use
241
+
- Use for the plan's final validation task after implementation is complete.
242
+
- Triggered by requests like "validate the plan", "run final checks", "confirm everything passes", "wrap up the task", or "sign off on this change".
243
+
244
+
## Validation checklist
245
+
1) **Run full test suite** - discover and run the project's primary test command (e.g., `pytest`, `npm test`, `go test ./...`, `cargo test`, `make test`). Check `package.json`, `Makefile`, `pyproject.toml`, or CI config files to find the right command.
246
+
2) **Run lint/format checks** - discover and run the project's lint and format tools (e.g., `eslint`, `ruff`, `golangci-lint`, `cargo clippy`, `make lint`). Check project config files such as `.eslintrc`, `pyproject.toml`, or `.golangci.yml`.
247
+
3) **Remove temporary scaffolding** - delete any debug code, temporary files, or intermediate artifacts introduced during the change.
248
+
4) **Verify context reflects final implemented behavior** - confirm that plan context and notes match the actual final state of the implementation.
249
+
5) **Confirm each success criterion has evidence** - for every success criterion defined in the plan, record concrete evidence (command output, exit code, screenshot reference, or file path).
250
+
251
+
### If checks fail
252
+
- **Fixable failures**: fix the issue, re-run the failing check, and update the report with the corrected output.
253
+
- **Non-trivial failures**: document the failure, the attempted fix, and the blocker in the report under "Failed checks and follow-ups". Escalate to the user before closing out.
254
+
- **Lint/format auto-fixes**: if the tool supports auto-fix (e.g., `ruff --fix`, `eslint --fix`), apply it, then re-run to confirm clean output.
255
+
256
+
## Validation report
257
+
Write to `context/plans/{plan_name}.md` including:
0 commit comments