Skip to content

Commit 8bf0476

Browse files
committed
skills: Refresh SCE skill guidance and mirrored metadata
1 parent 2358c14 commit 8bf0476

31 files changed

Lines changed: 391 additions & 81 deletions

File tree

.opencode/skills/sce-bootstrap-context/SKILL.md

Lines changed: 21 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
22
name: sce-bootstrap-context
3-
description: Use when user wants to Bootstrap SCE baseline context directory when missing.
3+
description: Creates the SCE (Shared Context Engineering) baseline `context/` directory structure — a set of markdown files and sub-folders used as shared project memory (overview, architecture, patterns, glossary, decisions, plans, handovers, and a temporary scratch space). Use when the `context/` folder is missing from the repository, when a user asks to initialise the project context, set up context, create baseline documentation structure, or when shared configuration files for project memory are absent.
44
compatibility: opencode
55
---
66

@@ -21,16 +21,36 @@ Create these paths:
2121
- `context/tmp/`
2222
- `context/tmp/.gitignore`
2323

24+
Use the following commands to create the directory structure:
25+
```bash
26+
mkdir -p context/plans context/handovers context/decisions context/tmp
27+
touch context/overview.md context/architecture.md context/patterns.md context/glossary.md context/context-map.md
28+
```
29+
2430
`context/tmp/.gitignore` content:
2531
```
2632
*
2733
!.gitignore
2834
```
2935

36+
## Validation
37+
After running the commands, verify all expected paths exist before proceeding:
38+
```bash
39+
ls context/overview.md context/architecture.md context/patterns.md context/glossary.md context/context-map.md context/plans context/handovers context/decisions context/tmp context/tmp/.gitignore
40+
```
41+
If any path is missing, re-create it before moving on.
42+
3043
## No-code bootstrap rule
3144
- If the repository has no application code, keep `overview.md`, `architecture.md`, `patterns.md`, and `glossary.md` empty or placeholder-only.
3245
- Do not invent implementation details.
3346

47+
Example placeholder content for empty files in a no-code repo:
48+
```markdown
49+
# Overview
50+
51+
> This section has not been populated yet. Add a high-level description of the project here.
52+
```
53+
3454
## After bootstrapping
3555
- Add baseline links in `context/context-map.md`.
3656
- Tell the user that `context/` should be committed as shared memory.
Lines changed: 63 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
22
name: sce-context-sync
3-
description: Use when user wants to Synchronize context files to match current code behavior after task execution.
3+
description: Use when user wants to update project documentation to reflect code changes, sync docs with code, refresh project context, or keep AI memory files accurate after completing an implementation task. Scans modified code, classifies the change significance, then updates or verifies Markdown context files under `context/` (overview, architecture, glossary, patterns, context-map, and domain files) so that durable AI memory stays aligned with current code truth.
44
compatibility: opencode
55
---
66

@@ -16,39 +16,77 @@ For every completed implementation task, run a sync pass over these shared files
1616
- `context/patterns.md`
1717
- `context/context-map.md`
1818

19-
Do not default to editing root context files on every task. First classify whether the task is an important change; then edit or verify accordingly.
19+
Classify whether the task is an important change before deciding to edit or verify root context files.
2020

2121
## Root context significance gating
22-
- Treat root context edits as required when a task introduces or changes cross-cutting behavior, repository-wide policy/contracts, architecture boundaries, or canonical terminology.
23-
- Treat root context edits as verify-only when a task is localized to a single feature/domain and no root-level behavior, architecture, or terminology changed.
24-
- When verify-only applies, keep root files unchanged and capture details in focused domain/workflow files instead.
25-
- When root updates are not needed, still verify `context/overview.md`, `context/architecture.md`, and `context/glossary.md` against code truth before declaring done.
26-
27-
## Domain file creation policy
28-
- Use domain files under `context/{domain}/` for detailed feature behavior.
29-
- If a feature does not cleanly fit an existing domain file, create a new domain file instead of deferring documentation.
30-
- If the feature appears to be part of a larger future domain, still document the implemented slice now in a focused file and link it to related context.
31-
- Prefer creating a small, precise domain file over overloading `overview.md` with detail.
32-
- If updates for the current feature/domain become too detailed or large for shared files, migrate that detail into `context/{domain}/` files and keep only concise pointers in shared files.
33-
- Whenever detail is migrated, add discoverability links in `context/context-map.md` and cross-link relevant context files (`overview.md`, `architecture.md`, `glossary.md`, `patterns.md`) as needed.
34-
35-
## Feature existence rule (required)
36-
- Every newly implemented feature must be discoverable from context.
37-
- Ensure at least one durable canonical description exists in either:
38-
- a domain file under `context/{domain}/`, or
39-
- `context/overview.md` (for cross-cutting/system features).
40-
- Ensure discoverability links are present from `context/context-map.md`.
41-
- Add glossary entries for any new domain language.
22+
- **Root edits required** - task introduces cross-cutting behavior, repository-wide policy/contracts, architecture boundaries, or canonical terminology changes.
23+
- **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.
24+
- Even when verify-only, still verify `context/overview.md`, `context/architecture.md`, and `context/glossary.md` against code truth before declaring done.
25+
26+
## Step-by-step sync pass workflow
27+
28+
1. **Classify the change** - Important change or verify-only (see [Classification Reference](#classification-reference) below).
29+
2. **Read the affected code** - Review modified files to understand what actually changed.
30+
3. **Verify root files** - Open `context/overview.md`, `context/architecture.md`, and `context/glossary.md`; confirm they match code truth.
31+
4. **Edit or skip root files** - Important change: update relevant root files. Verify-only: leave root files unchanged.
32+
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).
33+
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).
34+
7. **Update `context/context-map.md`** - Add or refresh discoverability links to any new or changed context files.
35+
8. **Add glossary entries** - For any new domain language introduced by the task.
36+
9. **Final check** - Confirm all updated files are <= 250 lines, diagrams are present where needed, and links use relative paths.
37+
38+
### Before/after example
39+
A task adds a new `PaymentGateway` abstraction used only in the payments domain (verify-only - domain-local).
40+
41+
**`context/glossary.md`** - unchanged (no new root-level terminology).
42+
43+
**New file: `context/payments/payment-gateway.md`:**
44+
```markdown
45+
# PaymentGateway
46+
47+
Abstraction over external payment processors (Stripe, Adyen).
48+
Defined in `src/payments/gateway/`.
49+
50+
## Contract
51+
- `charge(amount, token): Result`
52+
- `refund(chargeId): Result`
53+
54+
See also: [overview.md](../overview.md), [context-map.md](../context-map.md)
55+
```
56+
57+
**`context/context-map.md`** - updated with a link to `context/payments/payment-gateway.md`.
58+
59+
---
60+
61+
## Classification Reference
62+
63+
| Important change (root edits required) | Verify-only (root files unchanged) |
64+
|---|---|
65+
| New auth strategy replacing existing one - architecture + terminology | New field on an existing API response - localized, no architecture impact |
66+
| Background job queue used across multiple domains - cross-cutting | Bug fix in a single service's retry logic - no new root-level behavior |
67+
| Renaming a core concept (e.g., `Order` -> `Purchase`) - canonical terminology | New UI component added to an existing feature - no cross-cutting impact |
68+
69+
---
70+
71+
## Domain File Creation Policy
72+
73+
- Use `context/{domain}/` for detailed feature behavior.
74+
- If a feature does not cleanly fit an existing domain file, create a new one - do not defer documentation.
75+
- 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.
76+
- Prefer a small, precise domain file over overloading `overview.md` with detail.
77+
- 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`.
78+
79+
---
4280

4381
## Final-task requirement
4482
- In the final plan task (validation/cleanup), confirm feature existence documentation is present and linked.
45-
- If a feature was implemented but not represented in context, add the missing context entry before declaring the task done.
83+
- If a feature was implemented but not represented in context, add the missing entry before declaring the task done.
4684

4785
## Quality constraints
48-
- Keep one topic per file.
86+
- One topic per file.
4987
- Prefer concise current-state documentation over narrative changelogs.
5088
- Link related context files with relative paths.
5189
- Include concrete code examples when needed to clarify non-trivial behavior.
52-
- Every context file you create or update must stay at or below 250 lines; if it would exceed 250, split into focused files and link them.
90+
- Every context file must stay at or below 250 lines; if it would exceed 250, split into focused files and link them.
5391
- Add a Mermaid diagram when structure, boundaries, or flows are complex.
5492
- Ensure major code areas have matching context coverage.

.opencode/skills/sce-drift-analyzer/SKILL.md

Lines changed: 113 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,39 +1,141 @@
11
---
22
name: sce-drift-analyzer
3-
description: Use when user wants to analyze drift between context and code using structured collectors.
3+
description: Compares project documentation against actual code implementation to identify outdated, missing, or mismatched content — then produces a prioritized report with actionable fixes. Use when the user says docs are out of date, wants to sync documentation with code, suspects the spec no longer matches implementation, notices code comments or context files are stale, or asks whether documentation reflects the current codebase. Third-person: analyzes documentation-vs-implementation alignment using JavaScript collectors, writes a structured drift report, and asks the user before applying any changes.
44
compatibility: opencode
55
---
66

77
## What I do
88
- Collect context and code signals with pure JavaScript collectors.
9-
- Analyze semantic drift between documented state and implemented state.
9+
- Compare documented state against implemented state to find mismatches.
1010
- Produce a clear drift report with actionable fixes.
1111
- Ask the user what to do next before making edits.
1212

1313
## How to run this
1414
- If `context/` is missing, ask once whether to bootstrap SCE baseline.
1515
- If yes, create baseline and continue.
1616
- If no, stop and explain drift analysis requires `context/`.
17-
- Collect data:
17+
- Collect data using standard Node.js APIs:
1818

1919
```javascript
20-
const collectors = require("../../lib/drift-collectors.js");
21-
const data = await collectors.collectAll(process.cwd(), {
22-
sources: ["context", "code"],
23-
});
20+
const fs = require("fs");
21+
const path = require("path");
22+
const { execSync } = require("child_process");
23+
24+
const root = process.cwd();
25+
26+
// --- Collect context/ claims, paths, topics, and completed tasks ---
27+
function readContextFiles(contextDir) {
28+
const results = { claims: [], paths: [], topics: [], completedTasks: [] };
29+
if (!fs.existsSync(contextDir)) return results;
30+
31+
const walk = (dir) => fs.readdirSync(dir, { withFileTypes: true }).forEach(entry => {
32+
const full = path.join(dir, entry.name);
33+
if (entry.isDirectory()) return walk(full);
34+
if (!entry.name.endsWith(".md")) return;
35+
const text = fs.readFileSync(full, "utf8");
36+
const lines = text.split("
37+
");
38+
lines.forEach((line, i) => {
39+
// Collect quoted file/path claims (e.g. "handled by src/foo.ts")
40+
const pathClaim = line.match(/"([^"]*\.[a-z]{2,4})"/i);
41+
if (pathClaim) results.claims.push({ file: full, line: i + 1, raw: line.trim(), ref: pathClaim[1] });
42+
// Collect explicit path mentions (src/..., lib/..., etc.)
43+
const pathRef = line.match(/\b(src|lib|app|test|tests|dist)\/[\w\/\.\-]+/);
44+
if (pathRef) results.paths.push({ file: full, line: i + 1, ref: pathRef[0] });
45+
// Collect completed task markers
46+
if (/^\s*-\s*\[x\]/i.test(line)) results.completedTasks.push({ file: full, line: i + 1, raw: line.trim() });
47+
// Collect section headings as documented topics
48+
const heading = line.match(/^#{1,3}\s+(.+)/);
49+
if (heading) results.topics.push(heading[1].trim());
50+
});
51+
});
52+
walk(contextDir);
53+
return results;
54+
}
55+
56+
// --- Collect exported symbols and module paths from source code ---
57+
function readCodeSymbols(srcDirs) {
58+
const symbols = []; // { name, file }
59+
const allPaths = new Set();
60+
srcDirs.forEach(dir => {
61+
if (!fs.existsSync(dir)) return;
62+
const walk = (d) => fs.readdirSync(d, { withFileTypes: true }).forEach(entry => {
63+
const full = path.join(d, entry.name);
64+
if (entry.isDirectory()) return walk(full);
65+
const rel = path.relative(root, full);
66+
allPaths.add(rel);
67+
if (!/\.(js|ts|mjs|cjs)$/.test(entry.name)) return;
68+
const text = fs.readFileSync(full, "utf8");
69+
// Named exports: export function foo, export const foo, export class Foo
70+
const exportMatches = text.matchAll(/^export\s+(?:async\s+)?(?:function|const|class|let|var)\s+(\w+)/gm);
71+
for (const m of exportMatches) symbols.push({ name: m[1], file: rel });
72+
// module.exports.foo = ... or exports.foo = ...
73+
const cjsMatches = text.matchAll(/(?:module\.exports|exports)\.(\w+)\s*=/g);
74+
for (const m of cjsMatches) symbols.push({ name: m[1], file: rel });
75+
});
76+
});
77+
return { symbols, allPaths };
78+
}
79+
80+
const context = readContextFiles(path.join(root, "context"));
81+
const code = readCodeSymbols(["src", "lib", "app"].map(d => path.join(root, d)));
2482
```
2583

2684
- Analyze for these drift classes:
27-
- missing documentation (code capability not represented in `context/`)
28-
- outdated context (context claim no longer matches code)
29-
- structure drift (paths and boundaries changed)
30-
- completion drift (checked tasks with no supporting implementation)
85+
86+
- **Missing documentation** - a function or module exists in code but has no corresponding entry in `context/`
87+
```javascript
88+
const undocumented = code.symbols.filter(
89+
sym => !context.topics.some(t => t.toLowerCase().includes(sym.name.toLowerCase()))
90+
);
91+
```
92+
93+
- **Outdated context** - a path or file referenced in `context/` no longer exists on disk
94+
```javascript
95+
const stale = context.claims.filter(
96+
claim => {
97+
const abs = path.resolve(root, claim.ref);
98+
return !fs.existsSync(abs) && !code.allPaths.has(claim.ref);
99+
}
100+
);
101+
```
102+
103+
- **Structure drift** - file paths mentioned in `context/` have changed or moved
104+
```javascript
105+
const moved = context.paths.filter(
106+
p => !fs.existsSync(path.resolve(root, p.ref)) && !code.allPaths.has(p.ref)
107+
);
108+
```
109+
110+
- **Completion drift** - tasks marked `[x]` in `context/` reference paths or symbols with no evidence in code
111+
```javascript
112+
const phantom = context.completedTasks.filter(task => {
113+
const ref = task.raw.match(/\b(src|lib|app)\/[\w\/\.\-]+/);
114+
if (!ref) return false;
115+
return !fs.existsSync(path.resolve(root, ref[0])) && !code.allPaths.has(ref[0]);
116+
});
117+
```
118+
31119
- Write findings to `context/tmp/drift-analysis-YYYY-MM-DD.md`.
32120
- Ask user: "Apply these fixes?" with options:
33121
- Yes, apply all
34122
- Selectively
35123
- No, document only
36124

125+
## Expected drift finding format
126+
127+
Each finding in the report should follow this structure:
128+
129+
```
130+
[outdated-context] ARCHITECTURE.md line 12 claims "auth handled by middleware/session.js"
131+
-> File no longer exists. Auth now lives in src/auth/tokenGuard.ts.
132+
-> Fix: update ARCHITECTURE.md line 12 to reference src/auth/tokenGuard.ts.
133+
134+
[missing-documentation] src/payments/reconciler.ts exports `reconcileDaily()`
135+
-> No entry found in context/ for this capability.
136+
-> Fix: add reconciler capability to context/modules.md.
137+
```
138+
37139
## Rules
38140
- Treat code as source of truth when context and code disagree.
39141
- Keep findings concrete with file-level evidence.

.opencode/skills/sce-drift-fixer/SKILL.md

Lines changed: 19 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
22
name: sce-drift-fixer
3-
description: Use when user wants to audit and repair code-context drift in context/ using SCE rules.
3+
description: Use when the user wants to fix stale or outdated context documentation that no longer matches the actual codebase — e.g. "update docs", "sync context files", "fix outdated documentation", "refresh context", or "context is out of date". Audits files in `context/`, identifies discrepancies between documentation and implemented code (treating code as the source of truth), then updates context files to remove outdated references, correct stale descriptions, and sync documentation with recent code changes.
44
compatibility: opencode
55
---
66

@@ -17,11 +17,28 @@ compatibility: opencode
1717
- If no, stop and explain SCE workflows require `context/`.
1818
- Search `context/tmp/` for `drift-analysis-*.md`.
1919
- If one or more reports exist, use the latest report as the fix input.
20-
- If no report exists, explicitly tell the user no drift analysis report was found, then run `sce-drift-analyzer` to generate one before continuing.
20+
- If no report exists, explicitly tell the user no drift analysis report was found, then run `sce-drift-analyzer` by invoking the `sce-drift-analyzer` skill before continuing.
2121
- Ask whether to apply all fixes or apply selectively.
2222
- If any finding is ambiguous or lacks enough evidence, prompt the user before editing.
2323
- Keep context files concise, current-state oriented, and linked from `context/context-map.md` when relevant.
2424

25+
## Example drift finding and fix
26+
27+
**Finding from `context/tmp/drift-analysis-2024-11-01.md`:**
28+
> `context/architecture.md` line 12 states the auth module uses JWT tokens, but `src/auth/handler.ts` was refactored to use session cookies in commit `a3f92c1`.
29+
30+
**Before (`context/architecture.md`):**
31+
```markdown
32+
## Auth
33+
The auth module issues JWT tokens on login and validates them on each request.
34+
```
35+
36+
**After (`context/architecture.md`):**
37+
```markdown
38+
## Auth
39+
The auth module uses session cookies on login and validates the session on each request.
40+
```
41+
2542
## Expected output
2643
- A clear list of drift findings sourced from `context/tmp/drift-analysis-*.md`.
2744
- Explicit clarification questions for any uncertain drift items.

0 commit comments

Comments
 (0)