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
Copy file name to clipboardExpand all lines: README.en.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -154,10 +154,10 @@ On-demand extensions:
154
154
-**Architecture context**: `aisee:architecture` records technical facts, constraints, reusable capabilities, global engineering conventions, and artifact hints.
-**OpenSpec schema pack**: includes app, device, docsite, infra, security, quick-fix, quick-research, and collaboration schemas.
157
-
-**Context packs**: `aisee context pack`generates JSON context for implementation, verification, and review.
157
+
-**Context packs**: `aisee context pack`provides optional project memory and team knowledge injection for the current change without replacing OpenSpec facts.
158
158
-**Project memory**: `aisee memory` retrieves and writes current-repository long-lived guidance without replacing OpenSpec facts.
159
159
-**Team knowledge guardrails**: `aisee knowledge` retrieves a small number of reviewed engineering lessons through pack/card protocols without turning the knowledge repository into a second specification source.
160
-
-**Lightweight context routing**: `aisee context pack`parses sources, local numbers, candidate paths, and evidence entries when `source-map.md` exists.
160
+
-**Controlled memory injection**: `aisee context pack`injects `project_memory` or `knowledge` only when explicitly requested and does not own implementation-stage routing.
161
161
-**Verification and archive guardrails**: `aisee:verify` and `aisee:archive-guard` diagnose gaps and risks before archive.
162
162
-**Harness design**: CLI contract tests and normalized skill eval cases keep the workflow stable.
Before creating tasks, entering implementation, proposing reviewer lenses, or recommending a next step, check existing workflows and skills first:
162
161
163
162
- When there is no explicit change, return to requirements clarification, change-plan, or the current change itself rather than relying on a dedicated flow command.
164
-
- When there is an explicit change, read the target context pack first, such as `aisee context pack --change <change> --for ce-work --json`.
165
-
-`reusable_workflow_candidates` in the `ce-work` context pack is a routing hint only, not a source of truth.
166
-
- Use `ce-plan` only when `requires_ce_plan=true`; its conclusions must be written back to the current schema apply tracks, and only source-map schemas write back to `source-map.md`.
167
-
- When `requires_ce_plan=false` and paths/tasks are clear, prefer `aisee:implementation-bridge -> ce-work`.
163
+
- When there is an explicit change, read the current change artifacts, schema, `tasks.md`, `source-map.md` when applicable, and evidence entrypoints directly.
164
+
- Only read `aisee context pack --change <change> --for ce-work --project-memory --json` or `--knowledge --json` when you explicitly need that optional guidance.
165
+
-`aisee:implementation-bridge` should tell `ce-work` what to read first and how to write back `tasks.md` / apply tracks and evidence after implementation.
168
166
- Do not create execution, code-review, or test agents that overlap with CE responsibilities.
169
167
170
168
Interface, UI, hardware, firmware, security, and verification differences should remain schema-aware check lenses. When Aisee reviewers are needed, use only the read-only consistency roles `aisee-change-architect`, `aisee-spec-reviewer`, and `aisee-implementation-reviewer`.
0 commit comments