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
repo: Update generated SCE config contracts and policy assets
Align generated OpenCode assets, CLI config handling, and current-state
context with the latest SCE workflow contracts and config ownership rules.
This bundles command-wrapper metadata, bash-policy runtime support,
config-validation parity, and related context/plan updates in one repo-wide
sync.
description: "Create or update an SCE plan from a change request"
2
+
description: "Use `sce-plan-authoring` to turn a change request into a scoped SCE plan"
3
3
agent: "Shared Context Plan"
4
+
entry-skill: "sce-plan-authoring"
5
+
skills:
6
+
- "sce-plan-authoring"
4
7
---
5
8
6
9
Load and follow the `sce-plan-authoring` skill.
@@ -9,9 +12,9 @@ Input change request:
9
12
`$ARGUMENTS`
10
13
11
14
Behavior:
12
-
- Keep this command as thin orchestration; delegate clarification/ambiguity handling and plan-shape contracts to`sce-plan-authoring`.
13
-
-Ensure plan output follows one-task/one-atomic-commit slicing through `sce-plan-authoring` task-shape rules.
14
-
-Write/update `context/plans/{plan_name}.md`.
15
-
-Confirm plan creation with `{plan_name}` and exact path.
16
-
-Return the full ordered task list.
17
-
-Prompt user to start a new session to implement `T01` and provide`/next-task {plan_name} T01`.
15
+
- Keep this command as thin orchestration; detailed clarification handling, plan-shape rules, and task-writing behavior stay owned by`sce-plan-authoring`.
16
+
-Run `sce-plan-authoring` to resolve whether the input targets a new or existing plan, normalize goals/constraints/success criteria, and produce an implementation-ready task stack.
17
+
-Preserve the clarification gate from `sce-plan-authoring`: if blockers, ambiguity, or missing acceptance criteria remain, stop and ask the focused user questions needed to finish the plan safely.
18
+
-Require one-task/one-atomic-commit slicing through `sce-plan-authoring` before any task is considered ready for implementation.
19
+
-When the plan is ready, write or update `context/plans/{plan_name}.md`, confirm the resolved `{plan_name}` and exact path, and return the ordered task list.
20
+
-Stop after the planning handoff by providing the exact next-session command`/next-task {plan_name} T01`.
description: "Analyze and report drift between context and code"
2
+
description: "Run `sce-drift-analyzer` to report context-code drift before edits"
3
3
agent: "Shared Context Drift"
4
+
entry-skill: "sce-drift-analyzer"
5
+
skills:
6
+
- "sce-drift-analyzer"
4
7
---
5
8
6
9
Load and follow the `sce-drift-analyzer` skill.
7
10
8
11
Behavior:
9
-
-Collect structured signals from `context/`and code.
10
-
-Analyze mismatches between documented and implemented state.
11
-
-Save findings to `context/tmp/drift-analysis-YYYY-MM-DD.md`.
12
-
-Ask user whether to apply fixes or keep report-only output.
12
+
-Keep this command as thin orchestration; drift detection logic, evidence gathering, and report structure stay owned by `sce-drift-analyzer`.
13
+
-Run `sce-drift-analyzer` to compare `context/` against code truth, summarize mismatches, and write the drift report to `context/tmp/drift-analysis-YYYY-MM-DD.md`.
14
+
-Stop after the analyzer reports findings; do not apply fixes from this command.
15
+
-If the user wants repairs after reviewing the report, direct the next step to `/fix-drift` so update behavior stays owned by `sce-drift-fixer`.
description: "Resolve code-context drift using SCE rules"
2
+
description: "Run `sce-drift-fixer` to repair context files from current code truth"
3
3
agent: "Shared Context Drift"
4
+
entry-skill: "sce-drift-fixer"
5
+
skills:
6
+
- "sce-drift-fixer"
4
7
---
5
8
6
9
Load and follow the `sce-drift-fixer` skill.
7
10
8
-
Audit the `context/` and ensure it correctly describes the system as implemented
9
-
10
-
- treat code as authoritative
11
-
- summarize each discrepancy clearly
12
-
- propose exact context updates
13
-
- apply updates once the user confirms (or immediately if already authorized)
14
-
15
-
Make updates directly in `context/` and keep files concise, current-state oriented, and linked from `context/context-map.md` when relevant.
11
+
Behavior:
12
+
- Keep this command as thin orchestration; drift analysis, proposed repairs, and context edits stay owned by `sce-drift-fixer`.
13
+
- Run `sce-drift-fixer` to audit `context/` against implemented code, treat code as authoritative, and summarize the exact context updates needed.
14
+
- Preserve the fixer confirmation gate: apply updates only after explicit user confirmation unless the user already authorized fixes in the current session.
15
+
- After approved fixes are applied, stop with the updated context state and any follow-up verification notes from `sce-drift-fixer`.
description: "Create a structured SCE handover of the current task"
2
+
description: "Run `sce-handover-writer` to capture the current task for handoff"
3
3
agent: "Shared Context Code"
4
+
entry-skill: "sce-handover-writer"
5
+
skills:
6
+
- "sce-handover-writer"
4
7
---
5
8
6
9
Load and follow the `sce-handover-writer` skill.
7
10
8
11
Input:
9
12
`$ARGUMENTS`
10
13
11
-
Create a new handover file in `context/handovers/` that captures:
12
-
13
-
- current task state
14
-
- decisions made and rationale
15
-
- open questions or blockers
16
-
- next recommended step
17
-
18
-
Default naming should align with task execution handovers: `context/handovers/{plan_name}-{task_id}-{timestamp}.md`.
19
-
If key details are missing, infer what you can from the current repo state and clearly label assumptions.
14
+
Behavior:
15
+
- Keep this command as thin orchestration; handover structure, naming, and content decisions stay owned by `sce-handover-writer`.
16
+
- Run `sce-handover-writer` to gather current task state, decisions made and rationale, open questions or blockers, and the next recommended step.
17
+
- Let `sce-handover-writer` create the handover in `context/handovers/`, using task-aligned naming such as `context/handovers/{plan_name}-{task_id}-{timestamp}.md` when the inputs support it.
18
+
- If required details are missing, infer only from current repo state, label assumptions clearly, then stop after reporting the exact handover path.
description: "Review a plan and execute one SCE task from an approved plan"
2
+
description: "Run `sce-plan-review` -> `sce-task-execution` -> `sce-context-sync` for one approved SCE task"
3
3
agent: "Shared Context Code"
4
+
entry-skill: "sce-plan-review"
5
+
skills:
6
+
- "sce-plan-review"
7
+
- "sce-task-execution"
8
+
- "sce-context-sync"
9
+
- "sce-validation"
4
10
---
5
11
6
12
Load and follow `sce-plan-review`, then `sce-task-execution`, then `sce-context-sync`.
@@ -13,12 +19,12 @@ Expected arguments:
13
19
- task ID (`T0X`) (optional)
14
20
15
21
Behavior:
16
-
-Run `sce-plan-review` first to resolve plan target/task and readiness.
17
-
-Apply readiness confirmation gate from `sce-plan-review`:
18
-
- auto-pass only when both plan + task ID are provided and review reports no blockers/ambiguity/missing acceptance criteria
19
-
-otherwise resolve open points and ask user confirmation before execution
20
-
- Run `sce-task-execution`; keep mandatory implementation stop, scoped implementation, checks/lints/build, and plan status updates skill-owned.
21
-
- Run `sce-context-sync` as the required done gate.
22
-
-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.
23
-
- If this is the final plan task, run `sce-validation`.
24
-
- If more tasks remain, prompt a new session with `/next-task {plan_name} T0X`.
22
+
-Keep this command as thin orchestration; skill-owned review, implementation, validation, and context-sync details stay in the referenced skills.
23
+
-Run `sce-plan-review` first to resolve the plan target, choose the task, and report readiness.
24
+
- Apply the readiness confirmation gate from `sce-plan-review` before implementation:
25
+
-auto-pass only when both plan + task ID are provided and review reports no blockers, ambiguity, or missing acceptance criteria
26
+
- otherwise resolve the open points and ask the user to confirm the task is ready before continuing
27
+
- Run `sce-task-execution` next; keep the mandatory implementation stop, scoped edits, light checks/lints/build, and plan status updates skill-owned.
28
+
-After implementation, run `sce-context-sync` as the required done gate and wait for user feedback.
29
+
- If feedback requires in-scope fixes, apply the fixes, rerun light checks (and a light/fast build when applicable), then run `sce-context-sync` again.
30
+
- If this was the final plan task, run `sce-validation`; otherwise stop after prompting a new session with `/next-task {plan_name} T0X`.
description: "Run final validation and cleanup for an SCE plan"
2
+
description: "Run `sce-validation` to finish an SCE plan with validation and cleanup"
3
3
agent: "Shared Context Code"
4
+
entry-skill: "sce-validation"
5
+
skills:
6
+
- "sce-validation"
4
7
---
5
8
6
9
Load and follow the `sce-validation` skill.
@@ -9,6 +12,7 @@ Input:
9
12
`$ARGUMENTS`
10
13
11
14
Behavior:
12
-
- Run full validation checks.
13
-
- Capture evidence.
14
-
- Report pass/fail and any residual risks.
15
+
- Keep this command as thin orchestration; validation scope, command selection, cleanup, and evidence formatting stay owned by `sce-validation`.
16
+
- Run `sce-validation` to execute the full validation phase for the targeted plan or change, including required checks, evidence capture, and cleanup expected by the skill.
17
+
- Let `sce-validation` decide pass/fail status and record any residual risks or unmet criteria.
18
+
- Stop after reporting the validation outcome and the location of any written validation evidence.
"message": "This repository blocks direct `git add`, `git commit`, and `git push`. Use `jj` instead."
17
+
},
18
+
{
19
+
"id": "use-pnpm-over-npm",
20
+
"match": {
21
+
"argv_prefixes": [["npm"]]
22
+
},
23
+
"message": "This repository prefers `pnpm` over `npm`. Use `pnpm` instead."
24
+
},
25
+
{
26
+
"id": "use-bun-over-npm",
27
+
"match": {
28
+
"argv_prefixes": [["npm"]]
29
+
},
30
+
"message": "This repository prefers `bun` over `npm`. Use `bun` instead."
31
+
},
32
+
{
33
+
"id": "use-nix-flake-over-cargo",
34
+
"match": {
35
+
"argv_prefixes": [["cargo"]]
36
+
},
37
+
"message": "This repository prefers Nix flake entrypoints over direct `cargo` commands. Run Cargo through the documented `nix develop` / flake workflows instead."
0 commit comments