context-engineer 1.1.0 → 1.3.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/lib/update.mjs +45 -10
- package/package.json +1 -1
- package/templates/checksums.json +7 -7
- package/templates/claude/.claude/skills/dev-decompose/SKILL.md +3 -1
- package/templates/claude/.claude/skills/dev-execute/SKILL.md +10 -1
- package/templates/claude/.claude/skills/dev-prd/SKILL.md +27 -0
- package/templates/claude/.claude/skills/dev-quality/SKILL.md +27 -0
- package/templates/claude/.claude/skills/dev-requirements/SKILL.md +28 -6
- package/templates/claude/.claude/workflow/agents/reviewer.md +16 -3
- package/templates/claude/.claude/workflow/interfaces/phase-contract.md +2 -1
package/lib/update.mjs
CHANGED
|
@@ -30,6 +30,24 @@ function detectInstalledGroups(targetDir) {
|
|
|
30
30
|
return groups;
|
|
31
31
|
}
|
|
32
32
|
|
|
33
|
+
/**
|
|
34
|
+
* Framework files are the "engine" of context-engineer — skills, scripts, agent roles.
|
|
35
|
+
* These should always be updated, even if the user's copy differs (e.g., bootstrap touched them).
|
|
36
|
+
* Content files (.context/ project docs) contain user knowledge and should be preserved.
|
|
37
|
+
*/
|
|
38
|
+
function isFrameworkFile(relPath) {
|
|
39
|
+
const normalized = relPath.replace(/\\/g, '/');
|
|
40
|
+
if (normalized.startsWith('.claude/')) return true;
|
|
41
|
+
if (normalized.startsWith('.cursor/')) return true;
|
|
42
|
+
if (normalized.startsWith('scripts/')) return true;
|
|
43
|
+
if (normalized.startsWith('.github/')) return true;
|
|
44
|
+
if (normalized === 'CLAUDE.md') return true;
|
|
45
|
+
if (normalized === '.cursorrules') return true;
|
|
46
|
+
if (normalized === '.context/_meta/schema.md') return true;
|
|
47
|
+
if (normalized === '.context/_meta/drift-report.md') return true;
|
|
48
|
+
return false;
|
|
49
|
+
}
|
|
50
|
+
|
|
33
51
|
function loadInstalledChecksums(targetDir) {
|
|
34
52
|
const checksumPath = join(targetDir, '.context', '_meta', '.ce-checksums.json');
|
|
35
53
|
if (!existsSync(checksumPath)) return {};
|
|
@@ -70,8 +88,9 @@ export async function runUpdate(flags) {
|
|
|
70
88
|
const installedGroups = detectInstalledGroups(targetDir);
|
|
71
89
|
const installedChecksums = loadInstalledChecksums(targetDir);
|
|
72
90
|
|
|
73
|
-
// Categorize files: new,
|
|
91
|
+
// Categorize files into: new, framework (always update), updatable, customized (skip)
|
|
74
92
|
const newFiles = [];
|
|
93
|
+
const frameworkUpdates = [];
|
|
75
94
|
const updatable = [];
|
|
76
95
|
const customized = [];
|
|
77
96
|
|
|
@@ -95,15 +114,20 @@ export async function runUpdate(flags) {
|
|
|
95
114
|
continue;
|
|
96
115
|
}
|
|
97
116
|
|
|
98
|
-
//
|
|
99
|
-
|
|
117
|
+
// Framework files (skills, scripts, agent roles) are always updated
|
|
118
|
+
if (isFrameworkFile(relPath)) {
|
|
119
|
+
frameworkUpdates.push(relPath);
|
|
120
|
+
continue;
|
|
121
|
+
}
|
|
122
|
+
|
|
123
|
+
// Content files: check if user has customized since install
|
|
100
124
|
const originalHash = installedChecksums[relPath];
|
|
101
125
|
|
|
102
126
|
if (originalHash && currentHash === originalHash) {
|
|
103
127
|
// User hasn't modified it since install — safe to update
|
|
104
128
|
updatable.push(relPath);
|
|
105
129
|
} else {
|
|
106
|
-
// User has customized this file
|
|
130
|
+
// User has customized this content file — don't touch
|
|
107
131
|
customized.push(relPath);
|
|
108
132
|
}
|
|
109
133
|
}
|
|
@@ -117,19 +141,26 @@ export async function runUpdate(flags) {
|
|
|
117
141
|
console.log('');
|
|
118
142
|
}
|
|
119
143
|
|
|
144
|
+
if (frameworkUpdates.length > 0) {
|
|
145
|
+
console.log(` Framework updates (${frameworkUpdates.length}):`);
|
|
146
|
+
for (const f of frameworkUpdates) console.log(` ^ ${f}`);
|
|
147
|
+
console.log('');
|
|
148
|
+
}
|
|
149
|
+
|
|
120
150
|
if (updatable.length > 0) {
|
|
121
|
-
console.log(` Updatable
|
|
151
|
+
console.log(` Updatable content (${updatable.length}):`);
|
|
122
152
|
for (const f of updatable) console.log(` ~ ${f}`);
|
|
123
153
|
console.log('');
|
|
124
154
|
}
|
|
125
155
|
|
|
126
156
|
if (customized.length > 0) {
|
|
127
|
-
console.log(` Customized
|
|
157
|
+
console.log(` Customized content — preserved (${customized.length}):`);
|
|
128
158
|
for (const f of customized) console.log(` ! ${f}`);
|
|
129
159
|
console.log('');
|
|
130
160
|
}
|
|
131
161
|
|
|
132
|
-
|
|
162
|
+
const totalUpdates = newFiles.length + frameworkUpdates.length + updatable.length;
|
|
163
|
+
if (totalUpdates === 0) {
|
|
133
164
|
console.log(' No updates to apply.\n');
|
|
134
165
|
return;
|
|
135
166
|
}
|
|
@@ -140,14 +171,13 @@ export async function runUpdate(flags) {
|
|
|
140
171
|
}
|
|
141
172
|
|
|
142
173
|
// Confirm
|
|
143
|
-
const totalUpdates = newFiles.length + updatable.length;
|
|
144
174
|
const proceed = force || (await confirm(`Apply ${totalUpdates} update(s)?`));
|
|
145
175
|
if (!proceed) {
|
|
146
176
|
console.log(' Cancelled.\n');
|
|
147
177
|
return;
|
|
148
178
|
}
|
|
149
179
|
|
|
150
|
-
// Apply updates —
|
|
180
|
+
// Apply updates — new + framework (always) + updatable content + (force: customized content)
|
|
151
181
|
let applied = 0;
|
|
152
182
|
const newChecksums = { ...installedChecksums };
|
|
153
183
|
|
|
@@ -155,7 +185,12 @@ export async function runUpdate(flags) {
|
|
|
155
185
|
const groupDir = join(TEMPLATES_DIR, groupId);
|
|
156
186
|
if (!existsSync(groupDir)) continue;
|
|
157
187
|
|
|
158
|
-
const filesToUpdate = new Set([
|
|
188
|
+
const filesToUpdate = new Set([
|
|
189
|
+
...newFiles,
|
|
190
|
+
...frameworkUpdates,
|
|
191
|
+
...updatable,
|
|
192
|
+
...(force ? customized : []),
|
|
193
|
+
]);
|
|
159
194
|
|
|
160
195
|
for (const relPath of walkDir(groupDir)) {
|
|
161
196
|
if (!filesToUpdate.has(relPath)) continue;
|
package/package.json
CHANGED
package/templates/checksums.json
CHANGED
|
@@ -42,21 +42,21 @@
|
|
|
42
42
|
"claude/.claude/skills/bootstrap/SKILL.md": "7a1bda7ab0376188e261269a5d058083e21facc4834e6dd4c9190cc159695eb6",
|
|
43
43
|
"claude/.claude/skills/dev-capture/SKILL.md": "724bd8bbedb7f8b7311155f5e209c3964bc02ea39685973e7d22fd16f3f2bfd4",
|
|
44
44
|
"claude/.claude/skills/dev-commit/SKILL.md": "dc6b42e1f5264086d32a9942c820f8cf263408acdfb337a49d8d26eef7543424",
|
|
45
|
-
"claude/.claude/skills/dev-decompose/SKILL.md": "
|
|
45
|
+
"claude/.claude/skills/dev-decompose/SKILL.md": "c411822ce2d1de6a174fd91e41b0d05ab116a521cc4f1d9e3db36f65737b61b0",
|
|
46
46
|
"claude/.claude/skills/dev-deps/SKILL.md": "a279612324b00375975ef06b0530fefb5b5734573c78f019ff8d342c3a3067b1",
|
|
47
|
-
"claude/.claude/skills/dev-execute/SKILL.md": "
|
|
48
|
-
"claude/.claude/skills/dev-prd/SKILL.md": "
|
|
49
|
-
"claude/.claude/skills/dev-quality/SKILL.md": "
|
|
50
|
-
"claude/.claude/skills/dev-requirements/SKILL.md": "
|
|
47
|
+
"claude/.claude/skills/dev-execute/SKILL.md": "12acf3a18b3aab849224184d4bdc3415a09b595a4c6ebd43778aa2ac2a1567fb",
|
|
48
|
+
"claude/.claude/skills/dev-prd/SKILL.md": "c313548ef7afdecb4c76d27c879d06e70ea9fb9ee90e804ccf60b2ba7cecf808",
|
|
49
|
+
"claude/.claude/skills/dev-quality/SKILL.md": "566b127acb901ac857b085757ec3bab777f895326077ab02f361407e292c8392",
|
|
50
|
+
"claude/.claude/skills/dev-requirements/SKILL.md": "0127c4c10ba47da866b51b4b322f7d33902d44ace4ae3878d461ef297fb37d23",
|
|
51
51
|
"claude/.claude/skills/dev/SKILL.md": "ff82a44d8f9e177fcdee277a9969336457f8bbcd3461a709634bd3d2bee71c78",
|
|
52
52
|
"claude/.claude/skills/review-context/SKILL.md": "49716a96b75d6e78dbe2405bf835ce31e432ee5eb9c146b19c0592707de18231",
|
|
53
53
|
"claude/.claude/skills/sync/SKILL.md": "00c51e26c8b945810901831324086344d7ca9bb391796fb14afe0ee2a4c8ed33",
|
|
54
54
|
"claude/.claude/skills/update-context/SKILL.md": "203be9a9ba9dcaf97ef04973d3107192cb5bc3a98ba5a2a23409f676a6208c44",
|
|
55
55
|
"claude/.claude/workflow/agents/implementer.md": "ca1329f1a23f6359f4a1167804c9a2c8a0eb749bc3bd06dcdb0eeaf2e0506ba7",
|
|
56
|
-
"claude/.claude/workflow/agents/reviewer.md": "
|
|
56
|
+
"claude/.claude/workflow/agents/reviewer.md": "c2d07df9bd4125fcd7b95af24224f552c37dfcff06e6e1225bf1d5f98c02dc7b",
|
|
57
57
|
"claude/.claude/workflow/agents/team-config.md": "679a73ce17cd4dd0cbabf69ed665e840f4a21dc9b5f659c4bcd20c8e7b15f9a5",
|
|
58
58
|
"claude/.claude/workflow/agents/tester.md": "93b56bd201a6950e5a4cb66f5f0352a18b8c66c5619efd10fa84d7361c6bdff4",
|
|
59
|
-
"claude/.claude/workflow/interfaces/phase-contract.md": "
|
|
59
|
+
"claude/.claude/workflow/interfaces/phase-contract.md": "a01ca8553707035ea4a3f6511269cc527fc9cc49432dea416dae2b5a9a23b9b6",
|
|
60
60
|
"claude/CLAUDE.md": "a81997371fd35fec37fe38367f08d13256f68bd540a8bb126d908bbf4d2cc11d",
|
|
61
61
|
"cursor/.cursor/rules/always.mdc": "e653939afb8638e8ddd3bd081e8209632a8e004b466b8243029ea0fb77d2199f",
|
|
62
62
|
"cursor/.cursor/rules/backend.mdc": "1c42070f1a45ee2eafb2c24b9cc1da8e252c57a55941564134a07a9227e6336f",
|
|
@@ -41,6 +41,7 @@ Break the PRD's functional requirements into tasks. For each task:
|
|
|
41
41
|
3. **Set dependencies**: Identify which tasks must complete before others can start
|
|
42
42
|
4. **Write acceptance criteria**: Make them specific and testable
|
|
43
43
|
5. **Specify test requirements**: What tests should be written
|
|
44
|
+
6. **Provide implementation hints**: Give the implementing agent a head start with key technical details
|
|
44
45
|
|
|
45
46
|
**Task sizing guidance:**
|
|
46
47
|
- `small`: Single file change, < 50 lines, straightforward
|
|
@@ -80,7 +81,8 @@ Write `.context/workflow/artifacts/tasks.json` following this schema:
|
|
|
80
81
|
],
|
|
81
82
|
"context_files": ["architecture/api-surface.md"],
|
|
82
83
|
"complexity": "medium",
|
|
83
|
-
"test_requirements": "Unit tests for [what], integration test for [what]"
|
|
84
|
+
"test_requirements": "Unit tests for [what], integration test for [what]",
|
|
85
|
+
"implementation_hints": "Key function signatures, data structures, patterns to follow, or pseudocode for core logic. Optional for small/obvious tasks."
|
|
84
86
|
}
|
|
85
87
|
]
|
|
86
88
|
}
|
|
@@ -49,6 +49,11 @@ Create `.context/workflow/artifacts/execution-log.md`:
|
|
|
49
49
|
|
|
50
50
|
### Step 4: Execute Groups in Order
|
|
51
51
|
|
|
52
|
+
**Progress reporting**: Before each task, output a progress line:
|
|
53
|
+
```
|
|
54
|
+
[Group N/M] Task K/Total: T{id} — {title} ({pattern})
|
|
55
|
+
```
|
|
56
|
+
|
|
52
57
|
For each group in `dep-graph.json` (ordered by `order` field):
|
|
53
58
|
|
|
54
59
|
#### 4a. Determine Team Pattern for Each Task
|
|
@@ -170,7 +175,7 @@ Append to `execution-log.md` for each task:
|
|
|
170
175
|
- **Overall**: [PASS | FAIL]
|
|
171
176
|
```
|
|
172
177
|
|
|
173
|
-
### Step 5: Handle Failures
|
|
178
|
+
### Step 5: Handle Failures (Task-Level Recovery)
|
|
174
179
|
|
|
175
180
|
- **Implementer failure**: Log error, mark task failed. Dependent tasks in later groups cannot proceed.
|
|
176
181
|
- **Reviewer escalation** (2 rounds exceeded): Pause, show reviewer's feedback, ask human to decide.
|
|
@@ -178,6 +183,10 @@ Append to `execution-log.md` for each task:
|
|
|
178
183
|
- **Build failure after group**: Attempt one fix. If fails, stop and report.
|
|
179
184
|
- **Merge conflict**: Stop, show details, ask user.
|
|
180
185
|
|
|
186
|
+
**Task-level recovery**: When a task fails, record its status in `execution-log.md` and continue with other independent tasks. Failed tasks are listed in the summary so the user can:
|
|
187
|
+
1. Fix the issue manually, then re-run `/dev --from=execute` (skips already-completed tasks by checking execution-log.md)
|
|
188
|
+
2. Or modify the task in tasks.json and re-run
|
|
189
|
+
|
|
181
190
|
### Step 6: Finalize
|
|
182
191
|
|
|
183
192
|
After all groups complete, update execution log:
|
|
@@ -32,6 +32,23 @@ Consider:
|
|
|
32
32
|
- What data model changes might be needed?
|
|
33
33
|
- What API changes are needed?
|
|
34
34
|
|
|
35
|
+
### Step 2b: Explore Design Alternatives
|
|
36
|
+
|
|
37
|
+
Before committing to a design, explore **2-3 implementation approaches** and evaluate trade-offs:
|
|
38
|
+
|
|
39
|
+
1. **Identify candidate approaches**: Based on the architecture and requirements, list 2-3 viable designs
|
|
40
|
+
2. **Evaluate each** against these criteria:
|
|
41
|
+
- Complexity (how much code/change)
|
|
42
|
+
- Risk (what could go wrong)
|
|
43
|
+
- Alignment with existing patterns
|
|
44
|
+
- Performance implications
|
|
45
|
+
- Future extensibility
|
|
46
|
+
3. **Recommend one** and explain why, noting trade-offs of alternatives
|
|
47
|
+
|
|
48
|
+
Include this analysis in the PRD under a "Design Approach" section. This is NOT a full architecture document — keep it concise (5-15 lines), focused on the key decision and rationale.
|
|
49
|
+
|
|
50
|
+
**When to skip**: If there is only one reasonable approach (e.g., simple CRUD, straightforward bug fix), skip the alternatives analysis and note "Single viable approach — no alternatives analysis needed."
|
|
51
|
+
|
|
35
52
|
### Step 3: Generate PRD
|
|
36
53
|
|
|
37
54
|
Write `.context/workflow/artifacts/prd.md` with this structure:
|
|
@@ -67,6 +84,16 @@ Write `.context/workflow/artifacts/prd.md` with this structure:
|
|
|
67
84
|
- **Scalability**: [Scale expectations]
|
|
68
85
|
- **Compatibility**: [Browser, OS, API version requirements]
|
|
69
86
|
|
|
87
|
+
## Design Approach
|
|
88
|
+
### Recommended: [Approach Name]
|
|
89
|
+
[Brief description of the chosen approach and why it was selected]
|
|
90
|
+
|
|
91
|
+
### Alternatives Considered
|
|
92
|
+
| Approach | Pros | Cons |
|
|
93
|
+
|----------|------|------|
|
|
94
|
+
| [Alt 1] | [Pros] | [Cons — why not chosen] |
|
|
95
|
+
| [Alt 2] | [Pros] | [Cons — why not chosen] |
|
|
96
|
+
|
|
70
97
|
## Technical Design Notes
|
|
71
98
|
- **Affected modules**: [List of modules/components that need changes]
|
|
72
99
|
- **Data model changes**: [New entities, modified fields, migrations]
|
|
@@ -63,6 +63,21 @@ If any check fails:
|
|
|
63
63
|
|
|
64
64
|
2. **Second failure**: Do NOT attempt further fixes. Record the failure in the report and let the orchestrator handle it (pause for human guidance).
|
|
65
65
|
|
|
66
|
+
### Step 3b: Acceptance Verification
|
|
67
|
+
|
|
68
|
+
After technical checks (build/lint/test), verify that the implementation meets the requirements:
|
|
69
|
+
|
|
70
|
+
1. Read `.context/workflow/artifacts/tasks.json` for all task acceptance criteria
|
|
71
|
+
2. Read `.context/workflow/artifacts/execution-log.md` for implementation summaries
|
|
72
|
+
3. For each task, check every acceptance criterion:
|
|
73
|
+
- **Met**: The implementation clearly satisfies the criterion
|
|
74
|
+
- **Partially met**: Some aspects are implemented but incomplete
|
|
75
|
+
- **Not met**: The criterion is not addressed
|
|
76
|
+
- **Untestable**: The criterion cannot be verified from code alone (mark for manual check)
|
|
77
|
+
4. Report overall acceptance rate: `[met count] / [total criteria]`
|
|
78
|
+
|
|
79
|
+
**This step does NOT re-run the agent team.** It is a read-only verification. If criteria are not met, the report flags them for human review.
|
|
80
|
+
|
|
66
81
|
### Step 4: Generate Quality Report
|
|
67
82
|
|
|
68
83
|
Write `.context/workflow/artifacts/quality-report.md`:
|
|
@@ -94,6 +109,18 @@ Write `.context/workflow/artifacts/quality-report.md`:
|
|
|
94
109
|
- **Tests failed**: [count]
|
|
95
110
|
- **Failed tests**: [list of failing test names and error messages]
|
|
96
111
|
|
|
112
|
+
## Acceptance Verification
|
|
113
|
+
|
|
114
|
+
### Overall: [N/M criteria met]
|
|
115
|
+
|
|
116
|
+
| Task | Criterion | Status |
|
|
117
|
+
|------|-----------|--------|
|
|
118
|
+
| T1 | [criterion text] | [met | partially met | not met | untestable] |
|
|
119
|
+
| T1 | [criterion text] | [met | partially met | not met | untestable] |
|
|
120
|
+
|
|
121
|
+
### Unmet Criteria (if any)
|
|
122
|
+
- T[id]: [criterion] — [what's missing]
|
|
123
|
+
|
|
97
124
|
## Auto-Fix Attempts
|
|
98
125
|
- [Description of any auto-fix attempts and their outcomes]
|
|
99
126
|
|
|
@@ -24,15 +24,37 @@ Check if requirements were provided inline (as arguments to `/dev` or `/dev-requ
|
|
|
24
24
|
|
|
25
25
|
If requirements were provided inline:
|
|
26
26
|
- Use them directly as the raw input
|
|
27
|
+
- Still proceed to Step 2b (Requirements Exploration) to validate completeness
|
|
27
28
|
|
|
28
29
|
If no requirements were provided:
|
|
29
30
|
- Ask the user to describe what they want to build or change
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
31
|
+
|
|
32
|
+
### Step 2b: Requirements Exploration
|
|
33
|
+
|
|
34
|
+
**Proactively explore the requirements** — don't just accept raw input. Ask clarifying questions to fill gaps:
|
|
35
|
+
|
|
36
|
+
1. **Clarify ambiguity**: Identify vague terms and ask for specifics
|
|
37
|
+
- "What does 'fast' mean? Under 200ms? Under 1 second?"
|
|
38
|
+
- "When you say 'users', do you mean all users or a specific role?"
|
|
39
|
+
|
|
40
|
+
2. **Identify boundaries**: Define what's in and out of scope
|
|
41
|
+
- "Should this work for mobile/tablet or desktop only?"
|
|
42
|
+
- "Does this need to handle offline scenarios?"
|
|
43
|
+
|
|
44
|
+
3. **Explore edge cases**: Ask about non-obvious scenarios
|
|
45
|
+
- "What happens if the user already has [X]?"
|
|
46
|
+
- "How should error states be handled?"
|
|
47
|
+
- "What are the limits? (max items, max file size, concurrent users)"
|
|
48
|
+
|
|
49
|
+
4. **Assess risks**: Flag potential technical or business risks
|
|
50
|
+
- "This will require changes to [existing module] — is that acceptable?"
|
|
51
|
+
- "This introduces a new dependency on [service] — have you considered availability?"
|
|
52
|
+
|
|
53
|
+
5. **Check integration points**: Understand how this connects to existing features
|
|
54
|
+
- "How does this interact with [existing feature]?"
|
|
55
|
+
- "Will this affect any existing API contracts?"
|
|
56
|
+
|
|
57
|
+
**Important**: Don't over-question. Aim for 3-5 targeted questions that fill the most critical gaps. If requirements are already thorough, acknowledge that and proceed.
|
|
36
58
|
|
|
37
59
|
### Step 3: Structure Requirements
|
|
38
60
|
|
|
@@ -18,9 +18,10 @@ You are a **Code Reviewer** — a quality-focused agent responsible for reviewin
|
|
|
18
18
|
### Review Process
|
|
19
19
|
|
|
20
20
|
1. **Read the task specification**: Understand what was supposed to be implemented.
|
|
21
|
-
2. **Read the diff**:
|
|
22
|
-
3. **
|
|
23
|
-
4. **
|
|
21
|
+
2. **Read the diff**: Run `git diff` to examine all code changes made by the Implementer. Skip files marked `<!-- AUTO-GENERATED -->` — do not review auto-generated files.
|
|
22
|
+
3. **Load conventions**: Read `.context/conventions/code-style.md`, `.context/conventions/patterns.md`, and `.context/conventions/error-handling.md` (skip if they don't exist).
|
|
23
|
+
4. **Check against criteria**: Verify each acceptance criterion is met.
|
|
24
|
+
5. **Review for quality**: Check the following categories.
|
|
24
25
|
|
|
25
26
|
### Review Categories
|
|
26
27
|
|
|
@@ -47,6 +48,18 @@ You are a **Code Reviewer** — a quality-focused agent responsible for reviewin
|
|
|
47
48
|
- Functions/methods are reasonably sized
|
|
48
49
|
- No code duplication that should be abstracted
|
|
49
50
|
|
|
51
|
+
#### Performance
|
|
52
|
+
- No N+1 query patterns (fetching in loops instead of batching)
|
|
53
|
+
- No unnecessary iterations over large collections
|
|
54
|
+
- No blocking I/O on hot paths
|
|
55
|
+
- No large memory allocations that could be streamed
|
|
56
|
+
- No missing pagination for unbounded result sets
|
|
57
|
+
|
|
58
|
+
#### API Compatibility
|
|
59
|
+
- Public API signature changes are intentional and documented
|
|
60
|
+
- No accidental breaking changes to existing interfaces
|
|
61
|
+
- Response format changes are backward compatible (or explicitly noted as breaking)
|
|
62
|
+
|
|
50
63
|
#### Scope Compliance
|
|
51
64
|
- Only files in the task's scope were modified
|
|
52
65
|
- No unrelated changes were introduced
|
|
@@ -133,7 +133,8 @@ Reference it in `team-config.md` to include it in a collaboration pattern.
|
|
|
133
133
|
"acceptance_criteria": ["..."],
|
|
134
134
|
"context_files": ["architecture/..."],
|
|
135
135
|
"complexity": "small | medium | large",
|
|
136
|
-
"test_requirements": "..."
|
|
136
|
+
"test_requirements": "...",
|
|
137
|
+
"implementation_hints": "Key function signatures, data structures, patterns to follow. Optional for small tasks."
|
|
137
138
|
}
|
|
138
139
|
]
|
|
139
140
|
}
|