akili-specs 2.8.0 → 2.10.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/.claude/commands/akili-archive.md +2 -0
- package/.claude/commands/akili-audit.md +4 -0
- package/.claude/commands/akili-constitution.md +87 -20
- package/.claude/commands/akili-execute.md +6 -2
- package/.claude/commands/akili-propose.md +2 -0
- package/.claude/commands/akili-quick.md +2 -0
- package/.claude/commands/akili-seo.md +2 -0
- package/.claude/commands/akili-specify.md +4 -0
- package/.claude/commands/akili-test.md +5 -2
- package/.claude/commands/akili-validate.md +2 -0
- package/.claude/skills/caveman/SKILL.md +72 -0
- package/.claude/skills/cognitive-doc-design/SKILL.md +2 -0
- package/.claude/skills/software-architect/SKILL.md +109 -0
- package/.claude/skills/software-architect/references/agentic-ai.md +59 -0
- package/.claude/skills/software-architect/references/architecture-styles.md +67 -0
- package/.claude/skills/software-architect/references/design-patterns.md +70 -0
- package/.claude/skills/software-architect/references/nfr-scenarios.md +75 -0
- package/.claude/skills/software-architect/references/views-documentation.md +65 -0
- package/CHANGELOG.md +19 -0
- package/docs/commands/akili-constitution.md +5 -1
- package/docs/flow.md +19 -5
- package/docs/model-routing.md +92 -24
- package/docs/skills/README.md +2 -0
- package/docs/skills/caveman.md +38 -0
- package/docs/skills/governance.md +3 -1
- package/docs/skills/software-architect.md +32 -0
- package/package.json +1 -1
|
@@ -56,6 +56,8 @@ docs/specs/archive/2026-05-16-bugfix--login-redirect/
|
|
|
56
56
|
|
|
57
57
|
### Step 0: Load Context
|
|
58
58
|
|
|
59
|
+
**Model checkpoint:** This phase runs best on **T5 Fast-Cheap** (summarization and bookkeeping). If the project's `## Model Routing` registry (root `AGENTS.md`/`CLAUDE.md`) maps that tier to a model different from the current session model, tell the user in one line — e.g. *"This phase is T5 — the registry recommends `/model haiku`; you are on opus"* — and offer to switch (`/model …` in Claude Code, the model selector in OpenCode) at the first approval pause. Never block on this; continuing on the current model is always allowed.
|
|
60
|
+
|
|
59
61
|
**Token Optimization (Prompt Caching):** To maximize prompt caching, always read the constitutional baseline documents FIRST and in the exact same order across all sessions before reading task-specific files.
|
|
60
62
|
|
|
61
63
|
1. Confirm `docs/specs/$ARGUMENTS/` exists.
|
|
@@ -19,6 +19,8 @@ Detect and report drift between the project's specifications (PRD, UX/UI Design,
|
|
|
19
19
|
|
|
20
20
|
### Step 0: Read Project Specifications
|
|
21
21
|
|
|
22
|
+
**Model checkpoint:** This phase runs best on **T4 Context-Ingest** for the scan and **T3 Auditor** for judging drift. If the project's `## Model Routing` registry (root `AGENTS.md`/`CLAUDE.md`) maps that tier to a model different from the current session model, tell the user in one line — e.g. *"This phase is T4+T3 — the registry recommends `/model sonnet`; you are on haiku"* — and offer to switch (`/model …` in Claude Code, the model selector in OpenCode) at the first approval pause. Never block on this; continuing on the current model is always allowed.
|
|
23
|
+
|
|
22
24
|
First, read the constitutional documentation baseline in the repository:
|
|
23
25
|
|
|
24
26
|
1. `docs/prd.md`
|
|
@@ -44,6 +46,7 @@ Audit for discrepancies, classifying findings under the following categories:
|
|
|
44
46
|
* **Visual/Design Token Mismatch:** Colors, typography, spacing, or component structures used in the codebase that violate the styling tokens and design principles declared in `docs/ux-ui/design.md`.
|
|
45
47
|
* **Technical Constraints Violation:** Architectural layout in the codebase that conflicts with patterns (e.g. testing requirements, security rules, file structuring) documented in `docs/trd/trd.md`.
|
|
46
48
|
* **Agent Guide Drift:** Modules whose conventions clearly diverge from the root but lack a child `CLAUDE.md`/`AGENTS.md`, child guides missing from the parent's `## Module Guides` index, guide entries pointing at modules that no longer exist, or root-guide structure descriptions that no longer match the codebase.
|
|
49
|
+
* **Model Registry Drift:** The project's `## Model Routing` registry (root `AGENTS.md`/`CLAUDE.md`) names models the host tool no longer offers, uses dated model pins where a floating alias exists (violating the alias-first rule) without a recorded reason, is missing tiers or the author ≠ auditor note versus the packaged default in `docs/model-routing.md`, or the Step 8E agent wrappers (`.claude/agents/akili-*.md` / OpenCode agent config) declare models that contradict the registry. Report only — never edit the registry or wrappers during the audit.
|
|
47
50
|
|
|
48
51
|
### Step 3: Write Drift Report
|
|
49
52
|
|
|
@@ -87,6 +90,7 @@ A brief overview of the codebase alignment state and major areas of specificatio
|
|
|
87
90
|
| UX/UI Design / Screen Inventory | [Details] | [Aligned / Drifted] | |
|
|
88
91
|
| TRD (APIs/DB) | [Details] | [Aligned / Drifted] | |
|
|
89
92
|
| Agent Guides (root + `## Module Guides` index) | [Details] | [Aligned / Drifted] | |
|
|
93
|
+
| Model Routing (registry + Step 8E wrappers) | [Details] | [Aligned / Drifted] | |
|
|
90
94
|
|
|
91
95
|
## Recommended Next Steps
|
|
92
96
|
Specific actions to resolve the discrepancies (e.g., "Run `/akili-constitution` to enhance baseline", "Update `trd.md` with active REST APIs", or "Schedule a task to implement missing validation tests").
|
|
@@ -19,6 +19,8 @@ Establish or strengthen the project-wide AKILI-SPECS foundation. This command cr
|
|
|
19
19
|
|
|
20
20
|
### Step 0: Determine Project Mode and Foundation Setup
|
|
21
21
|
|
|
22
|
+
**Model checkpoint:** This phase runs best on **T4 Context-Ingest** for repository ingestion and **T1 Architect** for baseline synthesis (if no project registry exists yet, use the packaged default in `docs/model-routing.md`). If the project's `## Model Routing` registry (root `AGENTS.md`/`CLAUDE.md`) maps that tier to a model different from the current session model, tell the user in one line — e.g. *"Baseline synthesis is T1 — the default registry recommends `/model opus`; you are on haiku"* — and offer to switch (`/model …` in Claude Code, the model selector in OpenCode) at the first approval pause. Never block on this; continuing on the current model is always allowed.
|
|
23
|
+
|
|
22
24
|
Before classifying the repository, use the `brainstorming` skill to ask the user if this is a new project/MVP starting from 0, or if it is an existing project with an established structure.
|
|
23
25
|
|
|
24
26
|
Based on the response, classify the repository into one of three modes. The classification is non-destructive — it controls how aggressively the constitution drafts, scans, or preserves existing material.
|
|
@@ -34,7 +36,7 @@ For all three modes:
|
|
|
34
36
|
3. Ensure `docs/specs/general-setup/` exists.
|
|
35
37
|
4. Ensure root `CLAUDE.md` exists or is enhanced.
|
|
36
38
|
5. Ensure root `AGENTS.md` exists or is enhanced.
|
|
37
|
-
6. Ensure project-level `.agents/` exists with `leader.md`, `implementer.md`, `reviewer.md`, and `tester.md` (see Step
|
|
39
|
+
6. Ensure project-level `.agents/` exists with `leader.md`, `implementer.md`, `reviewer.md`, and `tester.md` (see Step 8B).
|
|
38
40
|
7. Default behavior is to enhance existing project docs in place instead of creating parallel copies.
|
|
39
41
|
|
|
40
42
|
The constitutional baseline must cover these files:
|
|
@@ -210,6 +212,8 @@ When the file already exists, refine it in place instead of replacing establishe
|
|
|
210
212
|
|
|
211
213
|
Create or enhance `docs/trd/trd.md` as the technical implementation blueprint.
|
|
212
214
|
|
|
215
|
+
**Required skill:** load `software-architect` before drafting the TRD and apply its Decision Spine throughout this step — capture NFRs as six-part quality-attribute scenarios with measurable responses, choose tactics, decide the robust-vs-lite tier and architecture style, bind design patterns to named problems, and document with C4 views plus ADRs.
|
|
216
|
+
|
|
213
217
|
**Use skills when relevant** (stack skills — load only the ones matching the project's stack; the same set feeds the `## Skill Map` in Step 8D):
|
|
214
218
|
|
|
215
219
|
- `nestjs-expert`
|
|
@@ -224,16 +228,18 @@ Create or enhance `docs/trd/trd.md` as the technical implementation blueprint.
|
|
|
224
228
|
**Required structure:**
|
|
225
229
|
|
|
226
230
|
1. System Overview
|
|
227
|
-
2.
|
|
228
|
-
3.
|
|
229
|
-
4.
|
|
230
|
-
5.
|
|
231
|
-
6.
|
|
232
|
-
7.
|
|
233
|
-
8.
|
|
234
|
-
9.
|
|
235
|
-
10.
|
|
236
|
-
11.
|
|
231
|
+
2. Architecture Overview & Decisions (C4 Context + Container with legends, style choice, robust-vs-lite tier decision, ADR index)
|
|
232
|
+
3. Quality Attribute Scenarios (Non-Functional Requirements — six-part scenarios with measurable responses and chosen tactics; security, performance, scalability, and availability always evaluated)
|
|
233
|
+
4. Domain Modules & Responsibilities
|
|
234
|
+
5. Data Model & Entities
|
|
235
|
+
6. API Surface & Contracts
|
|
236
|
+
7. Backend Workflows & Business Rules
|
|
237
|
+
8. Frontend Architecture & State Boundaries
|
|
238
|
+
9. Integration Points
|
|
239
|
+
10. Security & Authorization Model
|
|
240
|
+
11. Error Handling & Observability
|
|
241
|
+
12. Testing Strategy
|
|
242
|
+
13. Technical Constraints & Assumptions
|
|
237
243
|
|
|
238
244
|
---
|
|
239
245
|
|
|
@@ -241,6 +247,8 @@ Create or enhance `docs/trd/trd.md` as the technical implementation blueprint.
|
|
|
241
247
|
|
|
242
248
|
Create or enhance `docs/infrastructure.md` as the deployment and hosting blueprint.
|
|
243
249
|
|
|
250
|
+
The infrastructure shape derives from the TRD's robust-vs-lite tier decision (Step 5, `software-architect` skill) — never precedes it. Cite the tier decision and its ADR at the top of the document.
|
|
251
|
+
|
|
244
252
|
**Required structure:**
|
|
245
253
|
|
|
246
254
|
1. Target Environment (e.g., AWS, GCP, Vercel, On-prem)
|
|
@@ -291,7 +299,7 @@ The update should explain briefly:
|
|
|
291
299
|
- How module specs should be organized under `docs/specs/`
|
|
292
300
|
- Which skills should be used for common work in the project (the `## Skill Map` added in Step 8D)
|
|
293
301
|
- Whether CodeGraph is initialized and how agents should use it for existing-project analysis
|
|
294
|
-
- Which model to switch to per AKILI-SPECS phase (the `## Model Routing` registry added in Step
|
|
302
|
+
- Which model to switch to per AKILI-SPECS phase (the `## Model Routing` registry added in Step 8C)
|
|
295
303
|
|
|
296
304
|
Preserve the repository's existing `CLAUDE.md` and `AGENTS.md` conventions and extend them.
|
|
297
305
|
|
|
@@ -379,21 +387,28 @@ project guides so the project does not depend on the package's `docs/` after ins
|
|
|
379
387
|
must differ from the Implementer model. `/akili-test` is likewise split into its Leader (T5,
|
|
380
388
|
orchestration) and Tester(s) (T2, test authoring), with a note to prefer a Tester model different
|
|
381
389
|
from the Implementer (author ≠ tester).
|
|
382
|
-
4. The editable model registry table with columns `Tier | Claude Code | OpenCode | Fallback
|
|
383
|
-
|
|
384
|
-
|
|
385
|
-
|
|
386
|
-
|
|
387
|
-
|
|
390
|
+
4. The editable model registry table with columns `Tier | Claude Code | OpenCode | Fallback`, plus
|
|
391
|
+
an `Updated: <YYYY-MM>` stamp. **Alias-first rule:** the Claude Code column uses floating aliases
|
|
392
|
+
(`opus`, `sonnet`, `haiku`) — they always resolve to the latest generation, so the registry
|
|
393
|
+
survives model churn with zero edits; pin a dated model ID only when the user deliberately wants
|
|
394
|
+
to freeze a version, and record why. Fill the OpenCode column from the user's confirmed roster
|
|
395
|
+
(slugs are concrete — no alias mechanism); if it is unknown, leave clearly-marked
|
|
396
|
+
`<CONFIRM SLUG>` placeholders rather than guessing.
|
|
397
|
+
5. The instruction: *"To change models, edit only this registry table. Never pin a dated model name
|
|
398
|
+
where a floating alias exists. Model selection is guidance only in command prompts — never add
|
|
399
|
+
`model:` to command frontmatter; enforced bindings live only in the Step 8E agent wrappers."*
|
|
388
400
|
|
|
389
|
-
**Mode-specific policy (mirror Step
|
|
401
|
+
**Mode-specific policy (mirror Step 8B):**
|
|
390
402
|
|
|
391
403
|
- **Brand-new (Seed Setup):** insert the full `## Model Routing` section using the packaged defaults.
|
|
392
404
|
- **Legacy (Discovery Setup):** insert the section and, where detected, annotate the registry with
|
|
393
405
|
the project's actual tooling (e.g. note if the team already standardizes on a specific model).
|
|
394
406
|
- **Active AKILI-SPECS (Safe Update):** **do not overwrite** an existing customized registry. If the section
|
|
395
407
|
is missing, add it; if it exists, only fill gaps (missing tiers, missing author ≠ auditor note)
|
|
396
|
-
without changing the user's pinned models.
|
|
408
|
+
without changing the user's pinned models. Additionally, **flag stale entries**: compare the
|
|
409
|
+
project registry against the packaged default in `docs/model-routing.md` and list (do not edit)
|
|
410
|
+
entries that name models the tool no longer offers or dated pins that an alias would now cover —
|
|
411
|
+
the user decides whether to refresh them.
|
|
397
412
|
|
|
398
413
|
Confirm the user's available models before writing concrete identifiers: which tier they run in
|
|
399
414
|
Claude Code (and their plan's rate limits) and which models their OpenCode roster exposes.
|
|
@@ -428,6 +443,58 @@ is how they reach the agents.
|
|
|
428
443
|
|
|
429
444
|
---
|
|
430
445
|
|
|
446
|
+
### Step 8E: Bind Personas to Models (Tool-Native Agent Wrappers)
|
|
447
|
+
|
|
448
|
+
Offer to generate **tool-native agent definitions** that bind the `.agents/` personas to the models
|
|
449
|
+
in the `## Model Routing` registry (Step 8C). This turns model routing from guidance into
|
|
450
|
+
enforcement for the multi-agent fan-out — where most tokens are spent — and makes
|
|
451
|
+
**author ≠ auditor structural**: the Reviewer wrapper is pinned to a different model than the
|
|
452
|
+
Implementer wrapper in configuration, not by human discipline.
|
|
453
|
+
|
|
454
|
+
Ask the user first (one question): *"Bind the AKILI personas to models with native agent wrappers,
|
|
455
|
+
so the Implementer/Reviewer/Tester automatically run on their tier's model?"* If declined, skip
|
|
456
|
+
this step — the guidance-only flow keeps working.
|
|
457
|
+
|
|
458
|
+
**Per tool:**
|
|
459
|
+
|
|
460
|
+
- **Claude Code:** create project-level `.claude/agents/akili-leader.md`, `akili-implementer.md`,
|
|
461
|
+
`akili-reviewer.md`, and `akili-tester.md`. Each wrapper is thin:
|
|
462
|
+
|
|
463
|
+
```markdown
|
|
464
|
+
---
|
|
465
|
+
name: akili-implementer
|
|
466
|
+
description: AKILI Implementer — executes one spec task with strict scope and verification.
|
|
467
|
+
model: sonnet
|
|
468
|
+
---
|
|
469
|
+
Read `.agents/implementer.md` in the project root and adopt it fully as your persona and
|
|
470
|
+
operating contract before doing anything else.
|
|
471
|
+
```
|
|
472
|
+
|
|
473
|
+
Models come from the registry's Claude Code column as **aliases** (default: leader `haiku`,
|
|
474
|
+
implementer `sonnet`, reviewer `opus`, tester `sonnet`). Never copy the persona body into the
|
|
475
|
+
wrapper — `.agents/` stays the single source of truth.
|
|
476
|
+
|
|
477
|
+
- **OpenCode:** create the equivalent project agent definitions (`.opencode/agent/akili-*.md` or
|
|
478
|
+
the `agent` block of `opencode.json`, matching the user's OpenCode version) with `model:` set to
|
|
479
|
+
the registry's OpenCode slugs (default: implementer `opencode-go/glm-5.1`, reviewer
|
|
480
|
+
`opencode-go/deepseek-v4-pro`, leader `opencode-go/deepseek-v4-flash`).
|
|
481
|
+
|
|
482
|
+
- **Google Antigravity:** no per-agent model binding exists — skip wrapper generation and note in
|
|
483
|
+
the summary that Antigravity stays on guidance-only routing.
|
|
484
|
+
|
|
485
|
+
**Rules:**
|
|
486
|
+
|
|
487
|
+
1. The Reviewer wrapper's model MUST differ from the Implementer wrapper's model. If the registry
|
|
488
|
+
collapses them, escalate the Reviewer one tier before writing the wrappers.
|
|
489
|
+
2. Wrappers reference `.agents/<role>.md`; they never duplicate persona content. Editing a persona
|
|
490
|
+
requires no wrapper change; changing a model requires editing only the wrapper (or re-running
|
|
491
|
+
this step).
|
|
492
|
+
3. **Mode policy:** Brand-new/Legacy — create the wrappers when accepted. Active AKILI-SPECS —
|
|
493
|
+
never overwrite existing wrapper files; create only missing ones and flag model drift between
|
|
494
|
+
existing wrappers and the current registry.
|
|
495
|
+
|
|
496
|
+
---
|
|
497
|
+
|
|
431
498
|
### Step 9: Present and Confirm
|
|
432
499
|
|
|
433
500
|
After drafting or enhancing the documents, generate a short, easy-to-understand summary (summary facil de entender de lo que se hizo) covering:
|
|
@@ -52,17 +52,21 @@ If `.agents/` is missing, run `/akili-constitution` first to scaffold it. Do not
|
|
|
52
52
|
|
|
53
53
|
**Delegation mechanism by tool:**
|
|
54
54
|
|
|
55
|
-
- **Claude Code / OpenCode:** spawn a focused subagent (or sub-prompt context) seeded with the persona file plus the task/diff context.
|
|
56
|
-
- **Google Antigravity:** invoke `invoke_subagent` (or the equivalent workflow primitive) using prompts read from `.agents
|
|
55
|
+
- **Claude Code / OpenCode:** if the project has tool-native AKILI agent wrappers (scaffolded by `/akili-constitution` Step 8E — e.g. `.claude/agents/akili-implementer.md` / `akili-reviewer.md` with `model:` bindings from the `## Model Routing` registry), **spawn those named agents** so each role runs on its tier's model and author ≠ auditor is enforced by configuration. Otherwise, spawn a focused subagent (or sub-prompt context) seeded with the persona file plus the task/diff context.
|
|
56
|
+
- **Google Antigravity:** invoke `invoke_subagent` (or the equivalent workflow primitive) using prompts read from `.agents/` (no per-agent model binding — guidance-only routing).
|
|
57
57
|
|
|
58
58
|
The Leader does not write production code itself unless the rework loop is exhausted and the user has explicitly approved a fallback.
|
|
59
59
|
|
|
60
|
+
**Communication economy:** load the `caveman` skill and apply its Scope Contract to all transient output in this command — inter-agent messages (Leader ↔ Implementer/Reviewer briefs, reports, feedback relays) at `full`, user-visible progress lines at `lite`. It never applies to `execution.md` audit entries, PR descriptions, HITL summaries, Pivot blockers, or verbatim evidence (Reviewer FAIL reports pass unchanged — the Structured Feedback rule wins).
|
|
61
|
+
|
|
60
62
|
---
|
|
61
63
|
|
|
62
64
|
## Behavior
|
|
63
65
|
|
|
64
66
|
### Step 0: Load Context
|
|
65
67
|
|
|
68
|
+
**Model checkpoint:** This phase runs best on **T5 Fast-Cheap** for you as Leader — the Implementer/Reviewer route through the Step 8E agent wrappers (their own tier models) when present. If the project's `## Model Routing` registry (root `AGENTS.md`/`CLAUDE.md`) maps that tier to a model different from the current session model, tell the user in one line — e.g. *"The Leader loop is T5 — the registry recommends `/model haiku`; you are on opus"* — and offer to switch (`/model …` in Claude Code, the model selector in OpenCode) at the first approval pause. Never block on this; continuing on the current model is always allowed.
|
|
69
|
+
|
|
66
70
|
**Token Optimization (Prompt Caching):** To maximize prompt caching, always read the constitutional baseline documents FIRST and in the exact same order across all sessions before reading task-specific files.
|
|
67
71
|
|
|
68
72
|
1. Read the project constitutional docs (IN THIS ORDER):
|
|
@@ -55,6 +55,8 @@ Do not create `requirements.md`, `design.md`, or `tasks.md` in this command unle
|
|
|
55
55
|
|
|
56
56
|
### Step 0: Resolve Path And Load Context
|
|
57
57
|
|
|
58
|
+
**Model checkpoint:** This phase runs best on **T1 Architect** (deep reasoning). If the project's `## Model Routing` registry (root `AGENTS.md`/`CLAUDE.md`) maps that tier to a model different from the current session model, tell the user in one line — e.g. *"This phase is T1 — the registry recommends `/model opus`; you are on sonnet"* — and offer to switch (`/model …` in Claude Code, the model selector in OpenCode) at the first approval pause. Never block on this; continuing on the current model is always allowed.
|
|
59
|
+
|
|
58
60
|
**Token Optimization (Prompt Caching):** To maximize prompt caching, always read the constitutional baseline documents FIRST and in the exact same order across all sessions before reading task-specific files.
|
|
59
61
|
|
|
60
62
|
1. Resolve `$SPEC_PATH` using the path rules above.
|
|
@@ -60,6 +60,8 @@ State clearly which criterion failed and which command to run instead. Never sil
|
|
|
60
60
|
|
|
61
61
|
### Step 0: Load Minimal Context
|
|
62
62
|
|
|
63
|
+
**Model checkpoint:** This phase runs best on **T2 Coder** (small direct edit, light verification). If the project's `## Model Routing` registry (root `AGENTS.md`/`CLAUDE.md`) maps that tier to a model different from the current session model, tell the user in one line — e.g. *"This phase is T2 — the registry recommends `/model sonnet`; you are on opus"* — and offer to switch (`/model …` in Claude Code, the model selector in OpenCode) at the first approval pause. Never block on this; continuing on the current model is always allowed.
|
|
64
|
+
|
|
63
65
|
Keep context small — this is a trivial change, not a full spec run.
|
|
64
66
|
|
|
65
67
|
1. Read only what the change needs:
|
|
@@ -74,6 +74,8 @@ If any prerequisite is missing, stop and report exactly what is missing and how
|
|
|
74
74
|
|
|
75
75
|
### Phase 0: Setup
|
|
76
76
|
|
|
77
|
+
**Model checkpoint:** This phase runs best on **T3 Auditor** for audit findings and **T5 Fast-Cheap** for setup/formatting. If the project's `## Model Routing` registry (root `AGENTS.md`/`CLAUDE.md`) maps that tier to a model different from the current session model, tell the user in one line — e.g. *"The audit phase is T3 — the registry recommends `/model opus`; you are on haiku"* — and offer to switch (`/model …` in Claude Code, the model selector in OpenCode) at the first approval pause. Never block on this; continuing on the current model is always allowed.
|
|
78
|
+
|
|
77
79
|
1. Resolve the spec path. If `$ARGUMENTS` is a bare domain, set `SPEC_PATH = seo/<domain>`. Otherwise treat `$ARGUMENTS` as the literal spec path.
|
|
78
80
|
2. Create directory `docs/specs/$SPEC_PATH/` if it does not exist.
|
|
79
81
|
3. Read the constitutional templates and project context as defined in `akili-specify`:
|
|
@@ -61,6 +61,8 @@ When the spec is a **bug** — the proposal's Document Control says `Type: Bug`,
|
|
|
61
61
|
|
|
62
62
|
### Step 0: Setup
|
|
63
63
|
|
|
64
|
+
**Model checkpoint:** This phase runs best on **T1 Architect** for requirements/design (re-check at Phase 3: **T5 Fast-Cheap** for the tasks split, **T6 Multimodal** when visual design is in scope). If the project's `## Model Routing` registry (root `AGENTS.md`/`CLAUDE.md`) maps that tier to a model different from the current session model, tell the user in one line — e.g. *"Phases 1–2 are T1 — the registry recommends `/model opus`; you are on haiku"* — and offer to switch (`/model …` in Claude Code, the model selector in OpenCode) at the first approval pause. Never block on this; continuing on the current model is always allowed.
|
|
65
|
+
|
|
64
66
|
**Token Optimization (Prompt Caching):** To maximize prompt caching, always read the constitutional baseline documents FIRST and in the exact same order across all sessions before reading task-specific files.
|
|
65
67
|
|
|
66
68
|
1. Create directory `docs/specs/$ARGUMENTS/` if it does not exist.
|
|
@@ -177,6 +179,8 @@ Wait for the user's response before moving on.
|
|
|
177
179
|
|
|
178
180
|
Use `brainstorming` to explore trade-offs before writing.
|
|
179
181
|
|
|
182
|
+
If the feature is architecturally significant (a new module or service, a new integration or data flow, a persistence or communication-topology change, or any stated NFR impact), load `software-architect` and apply its Decision Spine: NFR scenarios with measurable responses, tactics, robust-vs-lite sizing, pattern selection bound to named problems, and ADR-style design decisions.
|
|
183
|
+
|
|
180
184
|
If the work includes meaningful UI/UX impact, use this skill preference:
|
|
181
185
|
|
|
182
186
|
- `ui-ux-pro-max` if available
|
|
@@ -50,13 +50,14 @@ If `.agents/tester.md` is missing, run `/akili-constitution` first to scaffold i
|
|
|
50
50
|
|
|
51
51
|
**Delegation mechanism by tool:**
|
|
52
52
|
|
|
53
|
-
- **Claude Code / OpenCode:** spawn a focused subagent (or sub-prompt context) seeded with `tester.md` plus the suite's context slice.
|
|
54
|
-
- **Google Antigravity:** invoke `invoke_subagent` (or the equivalent) using the prompt read from `.agents/tester.md
|
|
53
|
+
- **Claude Code / OpenCode:** if the project has a tool-native `akili-tester` agent wrapper (scaffolded by `/akili-constitution` Step 8E with a `model:` binding from the `## Model Routing` registry), **spawn that named agent** so each Tester runs on its tier's model — preferring a model different from the Implementer's (author ≠ tester). Otherwise, spawn a focused subagent (or sub-prompt context) seeded with `tester.md` plus the suite's context slice.
|
|
54
|
+
- **Google Antigravity:** invoke `invoke_subagent` (or the equivalent) using the prompt read from `.agents/tester.md` (no per-agent model binding — guidance-only routing).
|
|
55
55
|
|
|
56
56
|
**Token discipline — thin context per Tester (this is the core saving):**
|
|
57
57
|
|
|
58
58
|
- Give each Tester **only its slice**: its assigned suite, the specific requirements + Given/When/Then scenarios that suite must prove, and the project's test command. Never hand a Tester the full `requirements.md`/`design.md`/`tasks.md` unless a scenario genuinely needs it.
|
|
59
59
|
- Each Tester's context is discarded when it finishes, so per-suite contexts never accumulate in one growing window.
|
|
60
|
+
- Load the `caveman` skill and apply its Scope Contract: Leader→Tester context slices and Tester structured reports use `full` compression; `test-report.md`, `PRODUCT_BUG` escalations to the user, and verbatim evidence (requirement and Given/When/Then scenario text quoted in slices, test output, `STATUS:` lines, error strings) are never compressed.
|
|
60
61
|
- The Leader writes no tests itself unless the Deployment Rule below says to run inline, or a Tester exhausts its inner loop and the user approves a Leader fallback.
|
|
61
62
|
|
|
62
63
|
**Deployment Rule (how many Testers to spawn):**
|
|
@@ -76,6 +77,8 @@ The Leader decides the count from the spec's depth and the independence of the s
|
|
|
76
77
|
|
|
77
78
|
### Phase 0: Load Context (Leader)
|
|
78
79
|
|
|
80
|
+
**Model checkpoint:** This phase runs best on **T5 Fast-Cheap** for you as Leader — Testers route through the `akili-tester` wrapper (T2) when present. If the project's `## Model Routing` registry (root `AGENTS.md`/`CLAUDE.md`) maps that tier to a model different from the current session model, tell the user in one line — e.g. *"The Leader loop is T5 — the registry recommends `/model haiku`; you are on opus"* — and offer to switch (`/model …` in Claude Code, the model selector in OpenCode) at the first approval pause. Never block on this; continuing on the current model is always allowed.
|
|
81
|
+
|
|
79
82
|
**Token Optimization (Prompt Caching):** To maximize prompt caching, always read the constitutional baseline documents FIRST and in the exact same order across all sessions before reading task-specific files.
|
|
80
83
|
|
|
81
84
|
1. Read project-level context (IN THIS ORDER):
|
|
@@ -49,6 +49,8 @@ Use these result levels consistently:
|
|
|
49
49
|
|
|
50
50
|
### Phase 0: Load Context
|
|
51
51
|
|
|
52
|
+
**Model checkpoint:** This phase runs best on **T3 Auditor** — and it MUST resolve to a different model than the one that implemented the work (author ≠ auditor). If the project's `## Model Routing` registry (root `AGENTS.md`/`CLAUDE.md`) maps that tier to a model different from the current session model, tell the user in one line — e.g. *"This phase is T3 — the registry recommends `/model opus`; you are on sonnet, which also implemented the spec"* — and offer to switch (`/model …` in Claude Code, the model selector in OpenCode) at the first approval pause. Never block on this; continuing on the current model is always allowed.
|
|
53
|
+
|
|
52
54
|
**Token Optimization (Prompt Caching):** To maximize prompt caching, always read the constitutional baseline documents FIRST and in the exact same order across all sessions before reading task-specific files.
|
|
53
55
|
|
|
54
56
|
1. Read constitutional context (IN THIS ORDER):
|
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: caveman
|
|
3
|
+
description: "Trigger: token efficiency, 'less tokens', 'be brief', caveman mode, inter-agent communication in /akili-execute and /akili-test. Ultra-compressed communication style (~65% fewer output tokens, measured upstream) for TRANSIENT agent output only — technical substance stays, fluff dies. Never applies to persistent documents (cognitive-doc-design territory) or HITL approval gates."
|
|
4
|
+
license: MIT
|
|
5
|
+
metadata:
|
|
6
|
+
author: Julius Brussee
|
|
7
|
+
source: https://github.com/juliusbrussee/caveman
|
|
8
|
+
adapted-by: "Juan Carlos Cadavid — jcadavid.com"
|
|
9
|
+
adapted-for: "AKILI-SPECS"
|
|
10
|
+
binding: core
|
|
11
|
+
version: "1.0"
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
# Caveman — Token-Economy Communication for Transient Agent Output
|
|
15
|
+
|
|
16
|
+
Respond terse like smart caveman. All technical substance stay. Only fluff die.
|
|
17
|
+
|
|
18
|
+
In AKILI, output-token waste is **MUDA** (see `kaizen`). This skill is the preventive tactic: it compresses the style of *transient* agent output — the chatter nobody rereads — while the documents humans live with stay under `cognitive-doc-design`.
|
|
19
|
+
|
|
20
|
+
## Scope Contract (the AKILI boundary — read first)
|
|
21
|
+
|
|
22
|
+
| Output | Caveman? | Level |
|
|
23
|
+
|---|---|---|
|
|
24
|
+
| Inter-agent messages (Leader ↔ Implementer / Reviewer / Tester): task briefs, completion reports, status relays — the verbatim zones below always win (Reviewer/Tester reports relay unchanged) | **Yes** | `full` |
|
|
25
|
+
| Progress narration and status lines shown to the user mid-run | **Yes** | `lite` |
|
|
26
|
+
| Persistent artifacts: PRD, TRD, `requirements.md`, `design.md`, `tasks.md`, `execution.md` audit entries, `test-report.md`, PR descriptions, Kaizen log | **No** — `cognitive-doc-design` owns artifacts | off |
|
|
27
|
+
| HITL approval gates: option menus, blocker questions, end-of-task summaries the user decides on | **No** — decision quality > token savings | off |
|
|
28
|
+
| Security warnings, irreversible-action confirmations, Pivot Protocol blockers | **No** (upstream Auto-Clarity rule) | off |
|
|
29
|
+
| Verbatim evidence: requirement text and Given/When/Then acceptance criteria quoted in briefs/slices, error strings, Reviewer findings passed to rework, test output, code, commands | **Never compressed or paraphrased** | n/a |
|
|
30
|
+
|
|
31
|
+
One sentence to remember: *`cognitive-doc-design` owns artifacts; `caveman` owns transient agent output.*
|
|
32
|
+
|
|
33
|
+
## Rules (upstream, preserved)
|
|
34
|
+
|
|
35
|
+
Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). No tool-call narration, no decorative tables/emoji, no dumping long raw error logs unless asked — quote shortest decisive line. Standard tech acronyms OK (DB/API/HTTP); **never invent abbreviations** (cfg/impl/req/res/fn) — tokenizer splits them same as full word: zero tokens saved, reader still decodes. No causal arrows (→) — own token, saves nothing. Technical terms exact. Code blocks unchanged. Errors quoted exact.
|
|
36
|
+
|
|
37
|
+
Preserve the user's dominant language — compress the style, not the language (Spanish user gets Spanish caveman). Keep technical terms, code, API names, CLI commands, commit-type keywords, and exact error strings verbatim.
|
|
38
|
+
|
|
39
|
+
No self-reference: never announce or name the style, no "caveman mode on".
|
|
40
|
+
|
|
41
|
+
Pattern: `[thing] [action] [reason]. [next step].`
|
|
42
|
+
|
|
43
|
+
- Not: "Sure! I'd be happy to help. The issue you're experiencing is likely caused by..."
|
|
44
|
+
- Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
|
|
45
|
+
|
|
46
|
+
## Intensity Levels (upstream; AKILI uses `lite` and `full`)
|
|
47
|
+
|
|
48
|
+
| Level | What changes |
|
|
49
|
+
|---|---|
|
|
50
|
+
| **lite** | No filler/hedging. Keep articles + full sentences. Professional but tight |
|
|
51
|
+
| **full** | Drop articles, fragments OK, short synonyms. No tool-call narration, no decorative tables/emoji, no raw log dumps. Standard acronyms OK; no invented abbreviations |
|
|
52
|
+
| **ultra** | Strip conjunctions when unambiguous; one word when one word enough. Not used by AKILI defaults — allowed only if the user explicitly asks |
|
|
53
|
+
| wenyan-* | Classical-Chinese register variants from upstream; not used by AKILI |
|
|
54
|
+
|
|
55
|
+
Example — "Why React component re-render?"
|
|
56
|
+
- lite: "Your component re-renders because you create a new object reference each render. Wrap it in `useMemo`."
|
|
57
|
+
- full: "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`."
|
|
58
|
+
|
|
59
|
+
## Auto-Clarity (upstream, preserved and extended)
|
|
60
|
+
|
|
61
|
+
Drop caveman when: security warnings; irreversible-action confirmations; multi-step sequences where fragment order risks misread; compression itself creates ambiguity (`"migrate table drop column backup first"` — order unclear); the user asks to clarify or repeats a question. **AKILI extension:** every HITL pause is an Auto-Clarity zone by definition. Resume caveman after the clear part is done.
|
|
62
|
+
|
|
63
|
+
## AKILI-SPECS Integration
|
|
64
|
+
|
|
65
|
+
| AKILI moment | This skill's job |
|
|
66
|
+
|---|---|
|
|
67
|
+
| `/akili-execute` | Leader→Implementer briefs, Implementer completion reports, Leader relay of Reviewer feedback: `full`. Progress lines: `lite`. `execution.md` audit entries, PR descriptions, HITL summaries and Pivot blockers: **off** |
|
|
68
|
+
| `/akili-test` | Leader→Tester context slices and Tester structured reports: `full`. `test-report.md` and PRODUCT_BUG escalations to the user: **off** |
|
|
69
|
+
| Every other command | Not loaded. Documents and user-facing methodology output are `cognitive-doc-design` territory |
|
|
70
|
+
| `kaizen` | Token savings from compressed inter-agent chatter are measurable MUDA reduction; a retrospective may cite them |
|
|
71
|
+
|
|
72
|
+
Adaptation rules: the Structured Feedback rule of `/akili-execute` wins over compression — Reviewer FAIL reports pass to the next Implementer **unchanged, never paraphrased**; a Tester's `STATUS:` lines and evidence quotes are verbatim zones; when in doubt whether output is transient or persistent, treat it as persistent (off).
|
|
@@ -32,6 +32,8 @@ Use it especially for:
|
|
|
32
32
|
|
|
33
33
|
The AKILI templates in `docs/specs/general-setup/` win over the default Documentation Shape below — apply the Critical Patterns inside their structure.
|
|
34
34
|
|
|
35
|
+
**Boundary with `caveman`:** this skill owns *persistent artifacts* (documents humans reread — PRDs, TRDs, specs, reports, PR descriptions); `caveman` owns *transient agent output* (inter-agent messages, progress narration in `/akili-execute` and `/akili-test`). Never apply caveman compression to a document this skill governs, and never pad transient chatter with document structure.
|
|
36
|
+
|
|
35
37
|
## Critical Patterns
|
|
36
38
|
|
|
37
39
|
| Pattern | Rule |
|
|
@@ -0,0 +1,109 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: software-architect
|
|
3
|
+
description: "Trigger: TRD creation, architecture design, non-functional requirements (NFR), quality attributes (security, performance, scalability, availability), architecture styles (hexagonal, clean architecture, microservices, serverless, modular monolith), design patterns (adapter, bridge, builder, GoF), C4 diagrams, ADRs, robust-vs-lite stack sizing. Senior software architect skill: capture NFRs as testable scenarios, choose tactics, size the architecture tier, select patterns, document with C4 + ADRs."
|
|
4
|
+
license: MIT
|
|
5
|
+
metadata:
|
|
6
|
+
author: Juan Carlos Cadavid — jcadavid.com
|
|
7
|
+
binding: core
|
|
8
|
+
version: "1.0"
|
|
9
|
+
inspired-by: "SEI quality-attribute scenarios & tactics (Bass/Clements/Kazman, Software Architecture in Practice), Documenting Software Architectures: Views and Beyond (Clements et al., SEI), the C4 model (Simon Brown), Refactoring.Guru design patterns catalog (Alexander Shvets), Clean Architecture (Robert C. Martin), Hexagonal/Ports & Adapters (Alistair Cockburn), Google Cloud agentic AI architecture guides"
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# Software Architect — The AKILI Architecture & NFR Skill
|
|
13
|
+
|
|
14
|
+
This skill makes the agent operate as a **senior software architect**: the role accountable for translating business needs into system structure, identifying non-functional requirements before they become production incidents, selecting technology deliberately, and leaving every decision documented and justified. Architecture is decided by evidence, never by fashion.
|
|
15
|
+
|
|
16
|
+
> Requirements without measures are wishes. Patterns without problems are decoration. Infrastructure without a tier decision is gambling.
|
|
17
|
+
|
|
18
|
+
This file is the **core + router**: the decision method every architecture task needs, plus a table telling you which `references/` file to load. Read the core, then load exactly the reference(s) the task requires — never all of them.
|
|
19
|
+
|
|
20
|
+
## Activation Contract
|
|
21
|
+
|
|
22
|
+
Load this skill when:
|
|
23
|
+
|
|
24
|
+
- `/akili-constitution` reaches **Step 5 (TRD)** — the primary, automatic trigger. Step 6 (Infrastructure) inherits its tier decision.
|
|
25
|
+
- `/akili-specify` Phase 2 designs an **architecturally significant** feature: a new module or service, a new integration or data flow, a change to persistence or communication topology, or any stated NFR impact.
|
|
26
|
+
- The user asks for architecture review, NFR identification, technology/stack selection, or design-pattern guidance.
|
|
27
|
+
|
|
28
|
+
Not for trivial changes: `/akili-quick` work and single-component edits never need this skill.
|
|
29
|
+
|
|
30
|
+
## The Decision Spine (the AKILI method)
|
|
31
|
+
|
|
32
|
+
Every architecture engagement walks the same five steps, in order. Each step's output feeds the next; skipping a step means a later decision has no justification.
|
|
33
|
+
|
|
34
|
+
| # | Step | Question it answers | Output |
|
|
35
|
+
|---|---|---|---|
|
|
36
|
+
| 1 | **Scenario** | What must the system *withstand*? | NFRs as six-part quality-attribute scenarios with **measurable responses** |
|
|
37
|
+
| 2 | **Tactic** | What design decision satisfies each scenario? | Named tactics per attribute (e.g. replication, encapsulation, caching, rate limiting) |
|
|
38
|
+
| 3 | **Tier & Style** | How much architecture do these tactics justify? | Robust-vs-lite tier decision + architecture style (hexagonal, clean, microservices…) |
|
|
39
|
+
| 4 | **Pattern** | Which proven structures implement the style? | Design patterns bound to named problems, with rejected alternatives |
|
|
40
|
+
| 5 | **View & Record** | How does everyone else understand it? | C4 diagrams (with legend), ADRs for hard-to-undo decisions, TRD sections |
|
|
41
|
+
|
|
42
|
+
The spine is traceable in both directions: every pattern points back to a tactic, every tactic to a scenario, every scenario to a business driver. A reviewer (or `judgment-day`) must be able to ask "why does this exist?" at any node and get an answer from the document, not from memory.
|
|
43
|
+
|
|
44
|
+
## The Robust-vs-Lite Gate (Step 3 detail)
|
|
45
|
+
|
|
46
|
+
Default to **LITE**. Escalate to **ROBUST** only when a scenario's response measure cannot be met without it — and record the escalation as an ADR.
|
|
47
|
+
|
|
48
|
+
| Axis | LITE (default) | ROBUST (needs evidence) |
|
|
49
|
+
|---|---|---|
|
|
50
|
+
| Structure | Modular monolith, clean/hexagonal layering inside one deployable | Microservices / event-driven topology |
|
|
51
|
+
| Compute | Serverless or single managed runtime | Containers/orchestration, dedicated clusters |
|
|
52
|
+
| Data | One primary database + cache | Polyglot persistence, CQRS, event sourcing |
|
|
53
|
+
| Async | Direct calls + one queue where needed | Broker topology, sagas, streaming |
|
|
54
|
+
| AI | Single agent, managed LLM API | Multi-agent orchestration, self-hosted models |
|
|
55
|
+
|
|
56
|
+
Escalation triggers (any one, evidenced by a scenario): independent scaling of hot paths; team count > deployables; divergent availability targets per module; regulatory isolation; response measures a monolith demonstrably cannot meet. **"We might need it later" is not a trigger** — record it under Technical Constraints & Assumptions as a revisit condition instead. The tier decision is what `docs/infrastructure.md` (constitution Step 6) derives its shape from.
|
|
57
|
+
|
|
58
|
+
## Routing — load the matching reference
|
|
59
|
+
|
|
60
|
+
| If the task involves… | Read |
|
|
61
|
+
|---|---|
|
|
62
|
+
| Capturing/refining NFRs, quality-attribute scenarios, tactics per attribute (availability, performance, security, modifiability, scalability, observability, cost) | `references/nfr-scenarios.md` |
|
|
63
|
+
| Choosing architecture style — hexagonal, clean, modular monolith, microservices, event-driven, serverless, CQRS — and the robust-vs-lite matrix, incl. Node.js/TypeScript layer mapping | `references/architecture-styles.md` |
|
|
64
|
+
| Selecting or justifying design patterns (22-pattern GoF-based catalog), SOLID/design principles, tactic→pattern bridge | `references/design-patterns.md` |
|
|
65
|
+
| Documenting: C4 levels, choosing views per stakeholder, view template, ADR template, interface specs | `references/views-documentation.md` |
|
|
66
|
+
| AI/LLM system architecture: agent patterns (single, ReAct, sequential, coordinator…), component decisions (framework, memory, tools, runtime), RAG/vector storage | `references/agentic-ai.md` |
|
|
67
|
+
|
|
68
|
+
A full TRD normally needs `nfr-scenarios.md` + `architecture-styles.md`, and `views-documentation.md` when drawing views; load `design-patterns.md` only when module design starts, and `agentic-ai.md` only when the system embeds LLM/agent behavior.
|
|
69
|
+
|
|
70
|
+
## Hard Rules
|
|
71
|
+
|
|
72
|
+
1. **No NFR without a measure.** Every quality-attribute scenario ends in a response measure a tester could verify (number, threshold, or observable condition). "The system must be fast/secure/scalable" never appears in a document this skill touched.
|
|
73
|
+
2. **Minimum NFR sweep.** Always evaluate security, performance, scalability, and availability explicitly — plus modifiability, observability, and cost when the system will live longer than a prototype. Explicitly marking an attribute "not architecturally significant here" is valid output; silence is not.
|
|
74
|
+
3. **No pattern without a named problem.** A design pattern enters the design only bound to the problem it solves and the tactic it implements; state the simpler alternative it beat.
|
|
75
|
+
4. **Start lite, escalate with evidence** through the Robust-vs-Lite Gate; escalations become ADRs.
|
|
76
|
+
5. **ADRs for the hard-to-undo.** Decisions that are expensive to reverse, took real evaluation effort, or will confuse future readers get an ADR (issue → decision → alternatives → argument → implications). Never defer rationale.
|
|
77
|
+
6. **Every diagram has a legend.** C4 levels Context and Container are the default; Component only for complex containers; Code level almost never.
|
|
78
|
+
7. **Respect the stack, then challenge it.** Read the project's declared stack and `## Skill Map` first; propose deviations (e.g. Go for a hot path, Python for ML) only through an ADR with a scenario as evidence.
|
|
79
|
+
8. **Token frugality (MUDA).** Conceptual designs only — no implementation code in TRD/design documents. Load only the references the task needs. Reuse existing document sections instead of restating them.
|
|
80
|
+
|
|
81
|
+
## Output Contract — where the spine lands in the TRD
|
|
82
|
+
|
|
83
|
+
| Spine output | TRD home (`docs/trd/trd.md`) |
|
|
84
|
+
|---|---|
|
|
85
|
+
| C4 Context + Container, style choice, tier decision | `Architecture Overview & Decisions` |
|
|
86
|
+
| Six-part scenarios + chosen tactics | `Quality Attribute Scenarios (Non-Functional Requirements)` |
|
|
87
|
+
| ADR log (compact table + per-ADR entries) | `Architecture Overview & Decisions` |
|
|
88
|
+
| Pattern selections with justification | `Domain Modules & Responsibilities` / feature `design.md` §Design Decisions |
|
|
89
|
+
| Security scenarios & tactics detail | `Security & Authorization Model` |
|
|
90
|
+
| Observability scenarios detail | `Error Handling & Observability` |
|
|
91
|
+
| Tier consequences for deployment | `docs/infrastructure.md` (Step 6 input) |
|
|
92
|
+
|
|
93
|
+
In `/akili-specify`, the same outputs land in `design.md`: Architecture Overview, Design Decisions (ADR-style), and requirement-linked NFR scenarios.
|
|
94
|
+
|
|
95
|
+
## AKILI-SPECS Integration
|
|
96
|
+
|
|
97
|
+
| AKILI moment | This skill's job |
|
|
98
|
+
|---|---|
|
|
99
|
+
| `/akili-constitution` Step 5 (TRD) | Run the full Decision Spine; produce Architecture Overview & Decisions + Quality Attribute Scenarios sections; sweep the minimum NFR set against the PRD |
|
|
100
|
+
| `/akili-constitution` Step 6 (Infrastructure) | Hand over the tier decision — infrastructure shape derives from robust-vs-lite, never precedes it |
|
|
101
|
+
| `/akili-specify` Phase 2 (design.md) | Spine on feature scale: scenarios for the feature's NFR deltas, patterns for its module design, ADR-style Design Decisions |
|
|
102
|
+
| `judgment-day` review gate | The spine's traceability (scenario → tactic → pattern) is what the judges audit; keep every link explicit in the document |
|
|
103
|
+
| `/akili-execute` | Not loaded — implementers receive decisions through the TRD/design docs, not by re-running this skill |
|
|
104
|
+
|
|
105
|
+
Adaptation rules: PRD business goals are the only valid source of scenario stimuli (no invented requirements); the project `## Skill Map` and declared stack constrain style choices before preference does; scenario measures become test candidates for `/akili-test`'s non-functional checks.
|
|
106
|
+
|
|
107
|
+
## References (attribution)
|
|
108
|
+
|
|
109
|
+
Method synthesized and authored by Juan Carlos Cadavid for AKILI-SPECS, standing on: SEI quality-attribute scenarios and tactics (Bass, Clements & Kazman — *Software Architecture in Practice*), *Documenting Software Architectures: Views and Beyond* (Clements et al.), the C4 model (Simon Brown), the Refactoring.Guru pattern catalog (Alexander Shvets), Clean Architecture (Robert C. Martin), Hexagonal Architecture (Alistair Cockburn), and Google Cloud's agentic AI architecture guides.
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
# Agentic AI Architecture — Patterns & Component Decisions
|
|
2
|
+
|
|
3
|
+
For systems embedding LLM/agent behavior. The Decision Spine applies unchanged: token cost, latency, and accuracy are **quality-attribute scenarios** like any other — write measures first, then pick the pattern. The Robust-vs-Lite gate is strictest here because agent complexity multiplies token spend.
|
|
4
|
+
|
|
5
|
+
## Pattern Catalog — cheapest that meets the measure wins
|
|
6
|
+
|
|
7
|
+
### Single-agent (LITE — the default)
|
|
8
|
+
| Pattern | Idea | Choose when |
|
|
9
|
+
|---|---|---|
|
|
10
|
+
| **Single Agent** | One model + tools + system prompt, end-to-end | Start here. Most assistant/automation features |
|
|
11
|
+
| **ReAct loop** | Think → act → observe until done | Dynamic environments, multi-step tool use; accuracy > latency |
|
|
12
|
+
|
|
13
|
+
### Multi-agent (ROBUST — each needs a scenario)
|
|
14
|
+
| Pattern | Idea | Choose when | Cost profile |
|
|
15
|
+
|---|---|---|---|
|
|
16
|
+
| **Sequential** | Linear pipeline, output → input | Fixed repeatable stages (ingest → classify → draft) | Low |
|
|
17
|
+
| **Parallel** | Independent subagents, results synthesized | Decomposable subtasks; latency reduction | Medium |
|
|
18
|
+
| **Loop** | Repeat until exit condition | Iterative refinement; **hard termination guard required** | Runaway risk |
|
|
19
|
+
| **Review-Critique** | Generator + critic gate | High-accuracy output (audited code, compliance text) | +1 model call per cycle |
|
|
20
|
+
| **Coordinator** | Central agent routes to specialists dynamically | Adaptive triage; heterogeneous requests | High (routing calls) |
|
|
21
|
+
| **Hierarchical** | Recursive decomposition tree | Open-ended research-class problems | Very high |
|
|
22
|
+
| **Swarm** | Peer-to-peer agents, no orchestrator | Almost never justified in products | Highest |
|
|
23
|
+
|
|
24
|
+
### Cross-cutting
|
|
25
|
+
- **Human-in-the-Loop** — approval pauses at defined points; mandatory for high-stakes/irreversible actions (a security tactic, not an option).
|
|
26
|
+
- **Custom logic orchestration** — deterministic code decides the flow, agents fill steps; prefer this over agent-decides-everything when the workflow is known (cheaper, testable, debuggable).
|
|
27
|
+
|
|
28
|
+
Escalation rule: Single Agent → add tools → ReAct → Sequential/Custom logic → one specialized multi-agent pattern. Each step is an ADR citing the measure the previous step failed.
|
|
29
|
+
|
|
30
|
+
## Component Decision Axes
|
|
31
|
+
|
|
32
|
+
| Axis | LITE | ROBUST | Decision driver (scenario) |
|
|
33
|
+
|---|---|---|---|
|
|
34
|
+
| Model access | Managed API: Bedrock, OpenAI, Anthropic | Multi-model routing; fine-tuned/self-hosted | Cost/latency measures; data-residency security scenarios |
|
|
35
|
+
| Model choice | One capable default model | Router: small model first, escalate on confidence | Cost ceiling per request |
|
|
36
|
+
| Tools | Few function tools in-process | MCP servers / API-gateway-governed tools | Tool reuse across agents; governance requirements |
|
|
37
|
+
| Memory (short) | In-context only | Externalized session state (Redis/DynamoDB) | Horizontal scaling scenario — any multi-instance deploy forces this |
|
|
38
|
+
| Memory (long) / RAG | S3 Vectors + Bedrock KB, single index | OpenSearch vector store, hybrid search, reranking | Corpus size, recall measures, filter complexity |
|
|
39
|
+
| Runtime | Lambda / managed agent runtime | Containers (ECS/EKS) for long-running or stateful agents | Execution time limits, streaming needs |
|
|
40
|
+
| Guardrails | Provider-level (Bedrock Guardrails) + input validation | Dedicated eval/guard pipeline, red-team suite | Security & compliance scenarios |
|
|
41
|
+
|
|
42
|
+
AWS-first defaults (per AKILI expertise): Bedrock for orchestration/models, S3 Vectors for lite RAG, OpenSearch for robust retrieval, Step Functions for deterministic orchestration of agent steps; OpenAI/Anthropic APIs when the project's ecosystem or model requirements dictate.
|
|
43
|
+
|
|
44
|
+
## LLM-Specific NFR Scenarios (write these explicitly)
|
|
45
|
+
|
|
46
|
+
- **Cost:** `1000 requests/day → agent pipeline ⇒ ≤ $X/month; alarm at 80%` — token budget is a response measure.
|
|
47
|
+
- **Latency:** p95 including model calls; streaming-first for user-facing paths.
|
|
48
|
+
- **Accuracy/quality:** eval-set pass rate ≥ X% before deploy; regression evals in CI.
|
|
49
|
+
- **Safety/security:** prompt-injection resistance on tool-using paths (treat all retrieved/user content as untrusted input to tools); PII redaction before external model calls; auditable trace of every tool invocation (non-repudiation tactic).
|
|
50
|
+
- **Availability:** provider outage behavior — degrade to smaller model / cached answers / honest failure (graceful-degradation tactic + circuit breaker on the provider port).
|
|
51
|
+
- **Determinism boundary:** which steps must be reproducible (temperature 0, seeded, or code) vs creative — record as variability.
|
|
52
|
+
|
|
53
|
+
## Architecture Rules for LLM Systems
|
|
54
|
+
|
|
55
|
+
1. The model provider sits behind a **port** (hexagonal): swapping Bedrock ↔ OpenAI ↔ Anthropic touches one adapter — this is the modifiability tactic that pays for itself first.
|
|
56
|
+
2. Prompts and model config are **versioned artifacts** (config/defer-binding tactic), not string literals in code.
|
|
57
|
+
3. Every agent action is **observable**: correlation ID from user request through every model/tool call (traces are also the audit log).
|
|
58
|
+
4. Multi-agent is a distributed system: apply the same rigor — idempotency, timeouts, budgets-as-bulkheads (max tokens/steps per request).
|
|
59
|
+
5. In the C4 container view, model providers and vector stores are external systems/containers with labeled protocols; the trust boundary between them and user data is drawn explicitly.
|