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
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
# Architecture Styles & the Robust-vs-Lite Matrix
|
|
2
|
+
|
|
3
|
+
Style is chosen **after** scenarios and tactics exist (Decision Spine step 3). A style is a vocabulary of components/connectors plus constraints; it earns its place by satisfying the scenario set at the lowest complexity that works.
|
|
4
|
+
|
|
5
|
+
## Style Catalog — when each one wins
|
|
6
|
+
|
|
7
|
+
| Style | Core idea | Choose when scenarios show… | Watch out |
|
|
8
|
+
|---|---|---|---|
|
|
9
|
+
| **Layered / N-tier** | Presentation / business / data separation, dependencies point down | Simple CRUD systems, small teams, uniform scaling | Layer skipping, "lasagna" of anemic layers |
|
|
10
|
+
| **Hexagonal (Ports & Adapters)** | Domain core surrounded by ports (interfaces) and adapters (tech) | Modifiability scenarios: swap DB/API/provider without touching business rules | Overkill for pure pipelines/scripts |
|
|
11
|
+
| **Clean Architecture** | Entities → Use Cases → Interface Adapters → Frameworks; Dependency Rule points inward, framework-independent domain | Long-lived products, testability scenarios (domain testable without infra), multiple delivery mechanisms | Ceremony on tiny services; don't create 4 layers for a webhook |
|
|
12
|
+
| **Modular Monolith** | One deployable, hard module boundaries (enforced imports), per-module data ownership | Team ≤ ~8, uniform availability target, fast iteration + future split option | Boundary erosion — enforce with lint/build rules |
|
|
13
|
+
| **Microservices** | Independently deployable services, own data, contract-based communication | Independent scaling of hot paths, >1 team per deployable cadence, divergent availability/regulatory isolation | Distributed monolith; needs observability + delivery maturity first |
|
|
14
|
+
| **Event-Driven** | Producers/consumers via broker; choreography or orchestration | Async workflows, spiky load absorption, audit trails, fan-out | Eventual consistency is an ADR; idempotency + DLQs mandatory |
|
|
15
|
+
| **Serverless** | Functions + managed services, scale-to-zero | Spiky/unpredictable load, cost scenarios favoring pay-per-use, small ops team | Cold starts vs latency measures; vendor coupling is an accepted ADR |
|
|
16
|
+
| **CQRS / Event Sourcing** | Split write/read models; state as event log | Read/write asymmetry proven by measures; audit/replay requirements | The most-regretted premature escalation; demand hard evidence |
|
|
17
|
+
|
|
18
|
+
Styles compose: a serverless system with a hexagonal core, or microservices where each service is internally clean, are normal outcomes. Name the composition in the TRD.
|
|
19
|
+
|
|
20
|
+
## Robust-vs-Lite Decision Matrix (expanded)
|
|
21
|
+
|
|
22
|
+
Score each axis from the scenario set; the tier is decided per axis, not globally — a lite structure with robust data is valid.
|
|
23
|
+
|
|
24
|
+
| Axis | LITE default | Escalate to ROBUST when (scenario evidence) | ADR must state |
|
|
25
|
+
|---|---|---|---|
|
|
26
|
+
| Structure | Modular monolith (hexagonal/clean inside) | Hot path needs independent scaling; team topology exceeds one deploy cadence | Split boundaries + contract ownership |
|
|
27
|
+
| Compute | Serverless (Lambda) or one managed runtime (ECS/App Runner) | Sustained high utilization (serverless cost crossover), long-running/stateful work, cold starts break latency measures | Cost crossover math, latency data |
|
|
28
|
+
| Data | One primary DB + cache | Polyglot proven by access patterns; regulatory isolation; write/read asymmetry | Consistency model per store |
|
|
29
|
+
| Async | Direct calls; one queue for the genuinely async | Multi-step sagas, streaming volumes, cross-service choreography | Failure/compensation model |
|
|
30
|
+
| Delivery | One pipeline, trunk-based, IaC from day one | Many services × environments; progressive delivery needed by availability scenarios | Promotion + rollback strategy |
|
|
31
|
+
| AI | Single agent, managed API | Multi-agent only when task decomposition is proven (see `agentic-ai.md`) | Token cost order-of-magnitude |
|
|
32
|
+
|
|
33
|
+
Anti-rule: never escalate two axes "while we're at it." Each escalation cites its own scenario.
|
|
34
|
+
|
|
35
|
+
## Reference Stack Mapping (AKILI default expertise: AWS + Node.js/TypeScript)
|
|
36
|
+
|
|
37
|
+
Use the project's declared stack and `## Skill Map` first. When the project is greenfield and the user's ecosystem applies, these are the calibrated defaults — deviations (Go for CPU-bound hot paths, Python for ML/data) go through an ADR:
|
|
38
|
+
|
|
39
|
+
| Concern | LITE | ROBUST |
|
|
40
|
+
|---|---|---|
|
|
41
|
+
| API/backend | Lambda + API Gateway (Node/TS), or NestJS on a single runtime | NestJS services on ECS/EKS; Go for measured hot paths; FastAPI for ML-adjacent services |
|
|
42
|
+
| Frontend | Next.js / Astro (content) on managed hosting | Next.js/Angular with edge rendering, feature-flagged progressive delivery |
|
|
43
|
+
| Relational data | Single MySQL (RDS) / managed Postgres | Aurora, read replicas, partitioning; Oracle when the org mandates it |
|
|
44
|
+
| NoSQL | DynamoDB single-table for known access patterns | DynamoDB + streams; MongoDB for document-flexible domains |
|
|
45
|
+
| Async | SQS (+ one DLQ) | EventBridge/SNS fan-out, Step Functions sagas, Kinesis streaming |
|
|
46
|
+
| AI/RAG | Bedrock (or OpenAI/Anthropic API) + S3 Vectors | Bedrock multi-model routing, OpenSearch vector store, dedicated inference |
|
|
47
|
+
| IaC | CDK/SAM, one stack per app | CDK multi-stack/multi-account, pipelines per service |
|
|
48
|
+
|
|
49
|
+
## Clean/Hexagonal Layer Mapping for Node.js/TypeScript
|
|
50
|
+
|
|
51
|
+
The Dependency Rule: source dependencies point inward only; the domain imports nothing from outer layers; data crossing boundaries is plain structures.
|
|
52
|
+
|
|
53
|
+
```
|
|
54
|
+
src/
|
|
55
|
+
domain/ # entities, value objects, domain services, ports (interfaces) — zero framework imports
|
|
56
|
+
application/ # use cases orchestrating domain; transaction boundaries; input/output DTOs
|
|
57
|
+
infrastructure/ # adapters: repositories (MySQL/Dynamo/Mongo), external APIs, message producers
|
|
58
|
+
interfaces/ # delivery: HTTP controllers/resolvers (NestJS/Fastify), CLI, queue consumers
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
- NestJS: modules per bounded context; providers implement domain ports; controllers stay thin (map transport ↔ use case DTOs).
|
|
62
|
+
- Serverless: each handler is an `interfaces/` adapter invoking a use case — business logic never lives in the handler file.
|
|
63
|
+
- Test consequence (testability tactic): domain + application test with in-memory port fakes, no infra needed.
|
|
64
|
+
|
|
65
|
+
## Style → Scenario Traceability Block (TRD requirement)
|
|
66
|
+
|
|
67
|
+
End the Architecture Overview with a compact table: `Scenario ID → Tactic → Style/axis decision it justified`. If a style decision has no scenario row, it is preference — delete it or find its scenario.
|
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
# Design Patterns — Selection, Principles, and the Tactic→Pattern Bridge
|
|
2
|
+
|
|
3
|
+
Patterns enter a design only at Decision Spine step 4: bound to a named problem, implementing a chosen tactic, with the simpler alternative stated. Catalog basis: the Refactoring.Guru catalog (Alexander Shvets) — 22 of the 23 GoF patterns (Interpreter omitted).
|
|
4
|
+
|
|
5
|
+
## Design Principles (the review checklist above any pattern)
|
|
6
|
+
|
|
7
|
+
1. **Encapsulate what varies** — isolate the changing part behind a boundary before reaching for a pattern name.
|
|
8
|
+
2. **Program to an interface, not an implementation.**
|
|
9
|
+
3. **Favor composition over inheritance.**
|
|
10
|
+
4. **SOLID:** Single Responsibility · Open/Closed · Liskov Substitution · Interface Segregation · Dependency Inversion (the Dependency Rule of clean/hexagonal is DIP at architecture scale).
|
|
11
|
+
|
|
12
|
+
If a principle solves it, stop there — a pattern nobody needs is complexity (MUDA).
|
|
13
|
+
|
|
14
|
+
## Selection Table — problem → pattern
|
|
15
|
+
|
|
16
|
+
### Creational (object creation)
|
|
17
|
+
| You need to… | Pattern | Note |
|
|
18
|
+
|---|---|---|
|
|
19
|
+
| Decouple client from concrete classes it instantiates | **Factory Method** | First stop; evolves into the ones below |
|
|
20
|
+
| Create families of related objects consistently | **Abstract Factory** | Often composed of factory methods |
|
|
21
|
+
| Build complex objects step-by-step (many optional params) | **Builder** | Kills telescoping constructors |
|
|
22
|
+
| Clone configured objects instead of rebuilding | **Prototype** | |
|
|
23
|
+
| Exactly one instance, controlled access | **Singleton** | In DI ecosystems (NestJS), prefer container-scoped providers |
|
|
24
|
+
|
|
25
|
+
### Structural (composition)
|
|
26
|
+
| You need to… | Pattern | Note |
|
|
27
|
+
|---|---|---|
|
|
28
|
+
| Make an incompatible interface fit (legacy, 3rd-party SDK) | **Adapter** | The workhorse of hexagonal `infrastructure/` |
|
|
29
|
+
| Vary abstraction and implementation independently (2 dimensions) | **Bridge** | Prevents class explosion (e.g. notification kind × channel) |
|
|
30
|
+
| Part-whole trees treated uniformly | **Composite** | |
|
|
31
|
+
| Add responsibilities dynamically without subclassing | **Decorator** | Middleware/interceptors are this |
|
|
32
|
+
| One simple door to a complex subsystem | **Facade** | Use-case classes often act as facades |
|
|
33
|
+
| Share heavy immutable state across many instances | **Flyweight** | Rare in business apps |
|
|
34
|
+
| Control access: lazy, cache, guard, remote | **Proxy** | Repositories with caching layers |
|
|
35
|
+
|
|
36
|
+
### Behavioral (interaction & responsibility)
|
|
37
|
+
| You need to… | Pattern | Note |
|
|
38
|
+
|---|---|---|
|
|
39
|
+
| Pass a request through potential handlers | **Chain of Responsibility** | Validation/auth pipelines |
|
|
40
|
+
| Requests as objects (queue, log, undo, retry) | **Command** | Natural fit for queue-driven work |
|
|
41
|
+
| Traverse a collection without exposing structure | **Iterator** | Built into JS/TS; rarely hand-rolled |
|
|
42
|
+
| Centralize chatty peer-to-peer communication | **Mediator** | Orchestrators, event buses in-process |
|
|
43
|
+
| Snapshot/restore state without breaking encapsulation | **Memento** | |
|
|
44
|
+
| Notify dependents on state change (pub/sub) | **Observer** | In-process events; at system scale → event-driven style |
|
|
45
|
+
| Behavior changes with internal state (kill state conditionals) | **State** | Order/workflow lifecycles |
|
|
46
|
+
| Interchangeable algorithms behind one interface | **Strategy** | Pricing rules, retry policies, LLM model routing |
|
|
47
|
+
| Algorithm skeleton with overridable steps | **Template Method** | Prefer Strategy (composition) when possible |
|
|
48
|
+
| Add operations across a class hierarchy without touching it | **Visitor** | Last resort; heavy coupling to hierarchy |
|
|
49
|
+
|
|
50
|
+
## Tactic → Pattern Bridge (connects step 2 to step 4)
|
|
51
|
+
|
|
52
|
+
| Tactic (from `nfr-scenarios.md`) | Patterns that implement it |
|
|
53
|
+
|---|---|
|
|
54
|
+
| Prevent ripple / intermediary | Facade, Bridge, Mediator, Proxy, Adapter |
|
|
55
|
+
| Defer binding | Strategy, Abstract Factory, Dependency Injection (DIP), plugin registration |
|
|
56
|
+
| Encapsulation / swap providers | Adapter + port interfaces (hexagonal), Bridge |
|
|
57
|
+
| Retry / failover / degradation | Command (retryable units), Proxy (circuit breaker), Chain of Responsibility (fallbacks) |
|
|
58
|
+
| Caching / multiple copies | Proxy (cache-aside), Flyweight |
|
|
59
|
+
| Rate limiting / arbitration | Decorator or Proxy on the entry port; Command queues |
|
|
60
|
+
| Audit / undo / replay | Command + Memento; at system scale → event sourcing (ADR!) |
|
|
61
|
+
| Workflow state control | State, Template Method → Strategy |
|
|
62
|
+
| Test doubles / seams | All port-based patterns (Adapter, Strategy) via DIP |
|
|
63
|
+
|
|
64
|
+
## Justification Format (what lands in the document)
|
|
65
|
+
|
|
66
|
+
For each pattern decision, one compact line in Design Decisions:
|
|
67
|
+
|
|
68
|
+
`[Problem] → [Pattern] implementing [Tactic] for [Scenario ID] — simpler alternative rejected: [X, reason]`
|
|
69
|
+
|
|
70
|
+
Evolution guidance: start with the simplest member of a family (Factory Method before Abstract Factory; Strategy before a full plugin system) and record the trigger that would justify upgrading. Patterns are design-level reuse — cheaper than framework lock-in, more durable than copied code.
|
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
# NFR Scenarios & Tactics
|
|
2
|
+
|
|
3
|
+
Non-functional requirements are captured as **quality-attribute scenarios** (SEI six-part format) and satisfied by **tactics** — named design decisions that control the system's response to a stimulus. This file is the scenario template plus the tactics menu per attribute.
|
|
4
|
+
|
|
5
|
+
## The Six-Part Scenario (the only valid NFR format)
|
|
6
|
+
|
|
7
|
+
| Part | Meaning | Example (performance) |
|
|
8
|
+
|---|---|---|
|
|
9
|
+
| **Source** | Who/what generates the stimulus | 500 concurrent end users |
|
|
10
|
+
| **Stimulus** | The condition arriving at the system | submit checkout requests |
|
|
11
|
+
| **Environment** | System state when it arrives | normal operation, peak season |
|
|
12
|
+
| **Artifact** | Component(s) affected | order API + payment integration |
|
|
13
|
+
| **Response** | What the system does | process and confirm the order |
|
|
14
|
+
| **Response measure** | The testable threshold | p95 latency ≤ 800 ms, error rate < 0.1% |
|
|
15
|
+
|
|
16
|
+
Rules:
|
|
17
|
+
|
|
18
|
+
- Write scenarios one-per-line in compact form: `[Source] → [Stimulus] on [Artifact] during [Environment] ⇒ [Response] measured by [Measure]`.
|
|
19
|
+
- Every scenario must be **architecturally significant** (shapes structure, not just code) and **testable** (the measure feeds `/akili-test`).
|
|
20
|
+
- Derive stimuli from PRD goals and real usage claims only. If the PRD lacks the number, ask or state the assumption explicitly.
|
|
21
|
+
- 3–7 scenarios per attribute that matters; zero for attributes marked "not architecturally significant here" (that marking is itself required output).
|
|
22
|
+
|
|
23
|
+
Example measures by attribute (calibrate to the project, don't copy blindly): availability — monthly downtime budget, RTO/RPO; performance — p95/p99 latency, throughput at N concurrent users; security — time to detect/revoke, blast radius of a leaked credential; modifiability — "add a payment provider touching ≤ 2 modules"; scalability — 10× load with linear cost, no redesign; cost — monthly ceiling per environment; observability — MTTD < X min for a failing dependency.
|
|
24
|
+
|
|
25
|
+
## Tactics Menu per Attribute
|
|
26
|
+
|
|
27
|
+
A tactic is chosen to satisfy a scenario, then implemented by styles/patterns (see `architecture-styles.md`, `design-patterns.md`). Cite the tactic by name in the TRD next to its scenario.
|
|
28
|
+
|
|
29
|
+
### Availability
|
|
30
|
+
- **Detect faults:** health checks/heartbeat, exception handling, timeouts.
|
|
31
|
+
- **Recover:** retry with backoff, failover/replicas, checkpoints + transaction log, graceful degradation, circuit breaker.
|
|
32
|
+
- **Prevent:** transactions (atomic rollback), bulkheads/isolation, removal from service for maintenance.
|
|
33
|
+
|
|
34
|
+
### Performance
|
|
35
|
+
- **Control resource demand:** increase computational efficiency, reduce overhead, manage event rate, bound queue sizes, bound execution times.
|
|
36
|
+
- **Manage resources:** introduce concurrency, maintain multiple copies (caching, read replicas, CDN), increase available resources (scale up/out).
|
|
37
|
+
- **Arbitrate resources:** scheduling/priority policies, rate limiting, backpressure.
|
|
38
|
+
|
|
39
|
+
### Security
|
|
40
|
+
Properties: confidentiality, integrity, non-repudiation, availability, auditability.
|
|
41
|
+
- **Resist:** authentication (tokens, certs, MFA), authorization (per-role/least privilege), encrypt in transit + at rest, validate inputs, limit exposure (private networking, minimal surface).
|
|
42
|
+
- **Detect:** intrusion/anomaly detection, request filtering, audit logging.
|
|
43
|
+
- **Recover:** state restoration, credential rotation/revocation, traceable audit trail for attack identification.
|
|
44
|
+
|
|
45
|
+
### Modifiability
|
|
46
|
+
- **Localize changes:** semantic coherence (high cohesion / low coupling), anticipate expected changes, generalize modules.
|
|
47
|
+
- **Prevent ripple:** encapsulation, intermediaries (facade, bridge, mediator, strategy, proxy, factory, repository), stable interfaces.
|
|
48
|
+
- **Defer binding:** configuration files, feature flags, runtime registration/plugins, polymorphism, dependency injection.
|
|
49
|
+
|
|
50
|
+
### Testability
|
|
51
|
+
- Interface/implementation separation, dependency injection for substitutable test doubles, specialized test interfaces, internal state monitoring, deterministic seams (clock/random injected).
|
|
52
|
+
|
|
53
|
+
### Usability (architectural slice only)
|
|
54
|
+
- Runtime: feedback, cancel/undo support. Design-time: separate UI from application logic (the same tactic as modifiability's semantic coherence — MVC and descendants).
|
|
55
|
+
|
|
56
|
+
### Scalability (cloud-era extension)
|
|
57
|
+
- Statelessness (externalize session/state), horizontal scaling + load balancing, partitioning/sharding, async decoupling via queues, autoscaling policies, cache hierarchies, read/write splitting.
|
|
58
|
+
|
|
59
|
+
### Observability (cloud-era extension)
|
|
60
|
+
- Structured logging with correlation IDs, RED/USE metrics, distributed tracing, health/readiness endpoints, alerting on symptoms (SLOs) not causes, dashboards per audience.
|
|
61
|
+
|
|
62
|
+
### Cost / FinOps (cloud-era extension)
|
|
63
|
+
- Serverless/scale-to-zero for spiky loads, right-sizing + reserved capacity for steady loads, tiered storage lifecycle, cache to cut egress/compute, model routing (small model first) for LLM workloads, budget alarms as deploy artifacts.
|
|
64
|
+
|
|
65
|
+
## Trade-off Table (always disclose)
|
|
66
|
+
|
|
67
|
+
Tactics conflict; the TRD must say which side won and why (this feeds `judgment-day`):
|
|
68
|
+
|
|
69
|
+
| Tension | Typical resolution note |
|
|
70
|
+
|---|---|
|
|
71
|
+
| Performance ↔ Modifiability | Layers/indirection add hops; keep them until a scenario measure fails, then flatten the measured path only |
|
|
72
|
+
| Security ↔ Performance/Usability | Encrypt and authenticate by default; budget the latency in the performance measures |
|
|
73
|
+
| Availability ↔ Cost | Replicas and multi-AZ cost money; the availability scenario's downtime budget justifies (or caps) the spend |
|
|
74
|
+
| Scalability ↔ Consistency | Prefer strong consistency until a scenario demands otherwise; eventual consistency is an ADR, never an accident |
|
|
75
|
+
| Cost ↔ everything | Every ROBUST escalation names its monthly cost order-of-magnitude |
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
# Views & Documentation — C4, View Selection, ADRs, Interfaces
|
|
2
|
+
|
|
3
|
+
Documenting an architecture = documenting the relevant **views**, then adding what applies across views (rationale, mapping, roadmap). Views are chosen by stakeholder need, never by habit. Basis: C4 (Simon Brown) as notation + SEI Views & Beyond as method.
|
|
4
|
+
|
|
5
|
+
## C4 — the default notation
|
|
6
|
+
|
|
7
|
+
| Level | Diagram | Shows | Use |
|
|
8
|
+
|---|---|---|---|
|
|
9
|
+
| 1 | **System Context** | The system as one box + users/personas + neighboring systems. People and systems, not tech | Always — first diagram of every TRD |
|
|
10
|
+
| 2 | **Container** | Separately deployable/runnable units (web app, API, DB, queue, function) + tech choices + comm links | Always |
|
|
11
|
+
| 3 | **Component** | Major building blocks inside ONE container + responsibilities | Only for complex containers |
|
|
12
|
+
| 4 | Code (UML class) | Classes inside a component | Almost never; generate on demand |
|
|
13
|
+
|
|
14
|
+
Rules: every element carries name + type tag + one-line description (`[Container: NestJS/Node]`); every relationship is a labeled directed arrow; **every diagram has a legend** — shared abstractions matter more than notation. Supplementary diagrams reuse the same elements: a **deployment view** (containers → AWS infrastructure) and, when async flows exist, a **runtime/sequence view** for the 1–3 most critical scenarios. Mermaid is the default renderer in AKILI docs.
|
|
15
|
+
|
|
16
|
+
## Which views, for whom (selection method)
|
|
17
|
+
|
|
18
|
+
1. List stakeholders; keep candidate views having at least one vested stakeholder; 2. combine/drop overview-only views; 3. prioritize — 80% done breadth-first beats one perfect view; **never defer rationale**.
|
|
19
|
+
|
|
20
|
+
| Stakeholder | Needs (detail) |
|
|
21
|
+
|---|---|
|
|
22
|
+
| Developers / AKILI Implementer | Module structure + layer rules (d), their container's components (d), interfaces (d) |
|
|
23
|
+
| Tech lead / future architect | Everything + candid rationale (d) |
|
|
24
|
+
| Ops / infra | Deployment view (d), container view (s) |
|
|
25
|
+
| Testers / AKILI Tester | C&C behavior + interfaces + scenario measures (d) |
|
|
26
|
+
| PM / customer | Context (o), container (o), cost/tier decision (o) |
|
|
27
|
+
|
|
28
|
+
Quality-attribute → view mapping: performance → runtime + deployment views; security → deployment + data-flow + trust boundaries; modifiability → module/dependency view; availability → deployment + failover behavior. If a scenario matters, some view must let a reader analyze it.
|
|
29
|
+
|
|
30
|
+
## View documentation template (per view, compact)
|
|
31
|
+
|
|
32
|
+
1. **Primary presentation** (the diagram, with legend)
|
|
33
|
+
2. **Element catalog** — one line per element: responsibility + key properties
|
|
34
|
+
3. **Context** — what's in/out of scope for this view
|
|
35
|
+
4. **Variability** — variation points and binding times (config, flags, plugins)
|
|
36
|
+
5. **Rationale** — why this shape; link scenario/ADR IDs
|
|
37
|
+
|
|
38
|
+
Mark unused sections "n/a" — never silently omit. Avoid repetition: define an element once, cross-reference elsewhere.
|
|
39
|
+
|
|
40
|
+
## ADR — Architecture Decision Record (compact 8-field AKILI profile)
|
|
41
|
+
|
|
42
|
+
Full SEI template has 12 fields; AKILI uses 8 (drop bureaucracy, keep traceability):
|
|
43
|
+
|
|
44
|
+
```markdown
|
|
45
|
+
### ADR-NNN: <decision title>
|
|
46
|
+
- **Status:** proposed | accepted | superseded by ADR-MMM
|
|
47
|
+
- **Issue:** the forcing problem (link Scenario IDs)
|
|
48
|
+
- **Decision:** what was chosen
|
|
49
|
+
- **Alternatives:** options seriously considered
|
|
50
|
+
- **Argument:** why this one — cost, TCO, time-to-market, measures
|
|
51
|
+
- **Implications:** new constraints, renegotiated scope, revisit triggers
|
|
52
|
+
- **Related:** ADRs / requirements / affected artifacts
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
Document a decision when it is hard to undo, took real evaluation effort, is confusing without context, or is unusual enough to be "fixed" by mistake. ROI test: capture now if that's cheaper than rediscovery later. For contested choices, a trade-study table (rows = concerns/scenarios, columns = alternatives, cells = ✓/✗/?) replaces prose.
|
|
56
|
+
|
|
57
|
+
Keep an ADR index table at the top of Architecture Overview & Decisions: `ID | Title | Status | Scenarios`.
|
|
58
|
+
|
|
59
|
+
## Interface / contract documentation (per exposed interface)
|
|
60
|
+
|
|
61
|
+
1. Identity & version · 2. Resources/operations (syntax, semantics, errors) · 3. Data types · 4. Error model (shared) · 5. Variability · 6. Quality characteristics (SLO/SLA: latency, rate limits) · 7. Rationale · 8. Usage examples. In practice: OpenAPI/GraphQL schema covers 1–4; the TRD adds 5–8 — especially 6, where interface SLOs inherit from scenario measures.
|
|
62
|
+
|
|
63
|
+
## Seven rules for sound documentation (package checklist)
|
|
64
|
+
|
|
65
|
+
1. Write for the reader · 2. Avoid repetition · 3. Explain every notation (legends) · 4. Standard organization (templates above; mark gaps "TBD") · 5. Record rationale while fresh, including rejected options · 6. Version and release docs; avoid perpetual-draft drift · 7. Review with the real stakeholders (in AKILI: `judgment-day` is the structured review).
|
package/CHANGELOG.md
CHANGED
|
@@ -10,6 +10,25 @@ The format is inspired by Keep a Changelog and the repository follows semantic v
|
|
|
10
10
|
|
|
11
11
|
- No unreleased changes yet.
|
|
12
12
|
|
|
13
|
+
## [2.10.0] - 2026-07-22
|
|
14
|
+
|
|
15
|
+
### Added
|
|
16
|
+
|
|
17
|
+
- **New `caveman` skill** (by Julius Brussee, MIT — github.com/juliusbrussee/caveman; adapted for AKILI-SPECS): token-economy communication style (~65% output-token reduction in upstream benchmarks) scoped by an AKILI **Scope Contract** to *transient agent output only* — inter-agent messages in the `/akili-execute` triad and `/akili-test` Leader↔Tester communication at `full`, user-visible progress narration at `lite`. Explicitly OFF for persistent artifacts (PRD/TRD/specs/`execution.md`/`test-report.md`/PRs/Kaizen log — `cognitive-doc-design` territory), HITL approval gates, Pivot/`PRODUCT_BUG` escalations, and verbatim evidence (Reviewer FAIL reports, error strings, test output — the Structured Feedback rule wins). Boundary rule recorded in both skills: *"cognitive-doc-design owns artifacts; caveman owns transient agent output."* Wired into `/akili-execute` (Multi-Agent Triad) and `/akili-test` (Token discipline).
|
|
18
|
+
|
|
19
|
+
- **New `software-architect` skill** (by Juan Carlos Cadavid — jcadavid.com, MIT; original AKILI authorship): senior-software-architect skill built around the **Decision Spine** — Scenario → Tactic → Tier & Style → Pattern → View & Record. Captures non-functional requirements as six-part, measurable quality-attribute scenarios (SEI format) with a mandatory security/performance/scalability/availability sweep; sizes the architecture through a **robust-vs-lite gate** (evidence-based escalation recorded as ADRs, infrastructure derives from the tier); selects architecture styles (hexagonal, clean, modular monolith, microservices, event-driven, serverless) and GoF design patterns only when bound to named problems; documents with C4 views (legend required) and compact 8-field ADRs. Progressive disclosure via `references/` (nfr-scenarios, architecture-styles, design-patterns, views-documentation, agentic-ai — the latter covering single/multi-agent patterns, RAG/vector decisions, and LLM-specific NFRs). Wired into the methodology: `/akili-constitution` Step 5 (required skill for the TRD; the TRD structure gains `Architecture Overview & Decisions` and `Quality Attribute Scenarios (Non-Functional Requirements)` sections) and Step 6 (infrastructure cites the tier decision), and `/akili-specify` Phase 2 for architecturally significant features. Inspired by SEI (Bass/Clements/Kazman; Views & Beyond), the C4 model (Simon Brown), Refactoring.Guru (Alexander Shvets), Clean/Hexagonal architecture, and Google Cloud agentic AI guides.
|
|
20
|
+
## [2.9.0] - 2026-07-20
|
|
21
|
+
|
|
22
|
+
### Added
|
|
23
|
+
|
|
24
|
+
- **Model Routing 2.0 — enforced for subagents, guided for the main loop:**
|
|
25
|
+
- **Tool-native agent wrappers (`/akili-constitution` Step 8E):** with user approval, the constitution now binds the `.agents/` personas to the Model Routing registry via native agent definitions — `.claude/agents/akili-{leader,implementer,reviewer,tester}.md` in Claude Code (alias-based `model:`) and agent config in OpenCode (provider slugs). `/akili-execute` and `/akili-test` prefer these named agents, so the multi-agent fan-out (where most tokens are spent) routes automatically and **author ≠ auditor becomes structural** — the Reviewer wrapper pins a different model than the Implementer wrapper. Wrappers are thin references to `.agents/`; personas remain the single source of truth. Antigravity stays guidance-only (no per-agent model binding).
|
|
26
|
+
- **Model checkpoints in every command:** all 10 commands (`propose`, `specify`, `execute`, `test`, `validate`, `archive`, `audit`, `quick`, `seo`, `constitution`) perform a one-line, never-blocking check during setup — if the phase's tier maps to a different model than the current session, the user is told (e.g. "This phase is T1 — the registry recommends `/model opus`") and offered the switch at the first approval pause.
|
|
27
|
+
- **Model Registry Drift check in `/akili-audit`:** new drift category and Conformance Matrix row — registry entries naming models the tool no longer offers, dated pins where a floating alias exists, missing tiers/author ≠ auditor notes versus the packaged default, and Step 8E wrappers contradicting the registry. Report-only.
|
|
28
|
+
|
|
29
|
+
### Changed
|
|
30
|
+
|
|
31
|
+
- **Alias-first model registry (survives model churn):** `docs/model-routing.md` and the Step 8C scaffold now mandate floating aliases (`opus`/`sonnet`/`haiku` in Claude Code — they always resolve to the latest generation, so new model families require zero registry edits); dated model pins require a recorded reason. The default registry was rewritten alias-first with an `Updated:` stamp; OpenCode slugs (no alias mechanism) keep the Fallback column and are covered by the drift check. Safe Update mode now also flags stale registry entries against the packaged default without touching user pins.
|
|
13
32
|
## [2.8.0] - 2026-07-20
|
|
14
33
|
|
|
15
34
|
### Added
|
|
@@ -63,7 +63,11 @@ The `.agents/` directory is tool-agnostic: pure Markdown + YAML frontmatter, res
|
|
|
63
63
|
|
|
64
64
|
## Model Routing Scaffolding
|
|
65
65
|
|
|
66
|
-
Step
|
|
66
|
+
Step 8C adds or upgrades a `## Model Routing` section in the project's root `AGENTS.md` and `CLAUDE.md`: a capability-tier registry that maps each AKILI-SPECS phase to a model **per tool** (Claude Code and OpenCode), following the **alias-first rule** (floating aliases like `opus`/`sonnet`/`haiku` wherever they exist, so the registry survives model generations without edits). No `model:` frontmatter is added to commands and the installer is unchanged. The registry enforces **author ≠ auditor** (the Reviewer runs on a different model than the Implementer) and, in Active-AKILI-SPECS mode, is non-destructive: an existing customized registry is preserved, gaps are filled, and stale entries are flagged against the packaged default without touching user pins. See [Model Routing](../model-routing.md) for the tiers and the default registry.
|
|
67
|
+
|
|
68
|
+
## Model Binding Scaffolding (Tool-Native Agent Wrappers)
|
|
69
|
+
|
|
70
|
+
Step 8E (with the user's approval) binds the `.agents/` personas to the registry's models via **tool-native agent definitions**: `.claude/agents/akili-{leader,implementer,reviewer,tester}.md` in Claude Code (alias-based `model:` frontmatter) and the equivalent agent config in OpenCode (provider slugs). The wrappers are thin — they reference the `.agents/` persona instead of duplicating it — and make model routing **enforced** for the `/akili-execute` and `/akili-test` fan-out, including a structural author ≠ auditor guarantee (the Reviewer wrapper pins a different model than the Implementer wrapper). Antigravity has no per-agent model binding and stays guidance-only. In Active-AKILI-SPECS mode existing wrappers are never overwritten.
|
|
67
71
|
|
|
68
72
|
## Skill Map Scaffolding
|
|
69
73
|
|
package/docs/flow.md
CHANGED
|
@@ -303,11 +303,25 @@ T4 Context-Ingest, T5 Fast-Cheap, T6 Multimodal** — map to the phases:
|
|
|
303
303
|
| `/akili-audit` | T4 + T3 |
|
|
304
304
|
| `/akili-archive` | T5 |
|
|
305
305
|
|
|
306
|
-
A single editable registry binds each tier to a
|
|
307
|
-
|
|
308
|
-
|
|
309
|
-
|
|
310
|
-
|
|
306
|
+
A single editable registry binds each tier to a model **per tool** (Claude Code and OpenCode),
|
|
307
|
+
using **floating aliases** (`opus`/`sonnet`/`haiku`) wherever they exist so the registry survives
|
|
308
|
+
model generations without edits. `/akili-constitution` (Step 8C) scaffolds a `## Model Routing`
|
|
309
|
+
copy into the project's `AGENTS.md` / `CLAUDE.md`.
|
|
310
|
+
|
|
311
|
+
Routing operates at two levels:
|
|
312
|
+
|
|
313
|
+
* **Enforced (subagents):** `/akili-constitution` Step 8E can generate tool-native agent wrappers
|
|
314
|
+
(`.claude/agents/akili-{leader,implementer,reviewer,tester}.md` in Claude Code, agent config in
|
|
315
|
+
OpenCode) that pin each persona to its tier's model. `/akili-execute` and `/akili-test` prefer
|
|
316
|
+
those named agents — so **author ≠ auditor** (Reviewer model ≠ Implementer model) holds by
|
|
317
|
+
configuration on the fan-out where most tokens are spent.
|
|
318
|
+
* **Guided (main loop):** every command emits a one-line, never-blocking **model checkpoint** in
|
|
319
|
+
its setup step when the phase's tier maps to a different model than the current session.
|
|
320
|
+
|
|
321
|
+
No `model:` frontmatter on commands and no installer changes. `/akili-audit` reports **Model
|
|
322
|
+
Registry Drift** (stale model names, dated pins where an alias exists, wrappers contradicting the
|
|
323
|
+
registry). See [model-routing.md](model-routing.md) for the tiers, principles, and the default
|
|
324
|
+
registry.
|
|
311
325
|
|
|
312
326
|
### 8. The Kaizen Loop
|
|
313
327
|
|
package/docs/model-routing.md
CHANGED
|
@@ -4,8 +4,17 @@ AKILI is model-agnostic: no command, skill, or persona hardcodes a model. This d
|
|
|
4
4
|
**human-facing guidance** for choosing which model runs which AKILI-SPECS phase, so each phase runs on a
|
|
5
5
|
model matched to its dominant computational demand rather than one model doing everything.
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
|
|
7
|
+
Routing operates at two levels:
|
|
8
|
+
|
|
9
|
+
- **Enforced (subagents):** `/akili-constitution` Step 8E can bind the Implementer / Reviewer /
|
|
10
|
+
Tester / Leader personas to models via **tool-native agent definitions** (see
|
|
11
|
+
[Enforced routing](#enforced-routing-tool-native-agent-bindings)). This is where most tokens are
|
|
12
|
+
spent and where author ≠ auditor becomes structural instead of aspirational.
|
|
13
|
+
- **Guided (main loop):** the session model can only be switched by you (Claude Code `/model`,
|
|
14
|
+
OpenCode model selector). Commands emit a one-line **model checkpoint** when the phase's tier
|
|
15
|
+
points to a different model than the current session, so the switch happens at the right moment.
|
|
16
|
+
|
|
17
|
+
Nothing here is injected into command frontmatter or the installer — see
|
|
9
18
|
[Cross-Tool Safety](#cross-tool-safety).
|
|
10
19
|
|
|
11
20
|
## Philosophy: criteria first, model second
|
|
@@ -75,25 +84,35 @@ tier (to the deeper reasoner) to preserve independence.
|
|
|
75
84
|
## Model registry
|
|
76
85
|
|
|
77
86
|
This is the single editable source of truth. Phases reference **tiers**; only this table names
|
|
78
|
-
|
|
87
|
+
models. When models change, edit only this table. *Registry updated: 2026-07.*
|
|
79
88
|
|
|
80
|
-
|
|
89
|
+
**Alias-first rule: never pin a dated model name where a floating alias exists.** Claude Code's
|
|
90
|
+
`opus` / `sonnet` / `haiku` aliases always resolve to the latest version of each family — when
|
|
91
|
+
Anthropic ships a new generation, an alias-based registry needs **zero edits**. Pin a dated ID only
|
|
92
|
+
when you deliberately need to freeze a version, and record why next to the pin. OpenCode slugs are
|
|
93
|
+
concrete (no alias mechanism), which is why they carry the Fallback column and the drift check
|
|
94
|
+
below.
|
|
95
|
+
|
|
96
|
+
| Tier | Claude Code | OpenCode Go | Fallback |
|
|
81
97
|
|---|---|---|---|
|
|
82
|
-
| **T1 Architect** |
|
|
83
|
-
| **T2 Coder** |
|
|
84
|
-
| **T3 Auditor** |
|
|
85
|
-
| **T4 Context-Ingest** |
|
|
86
|
-
| **T5 Fast-Cheap** |
|
|
87
|
-
| **T6 Multimodal** |
|
|
98
|
+
| **T1 Architect** | `opus` *(alias — always latest)* | `opencode-go/kimi-k2.6` | `opencode-go/deepseek-v4-pro` / `sonnet` |
|
|
99
|
+
| **T2 Coder** | `sonnet` | `opencode-go/glm-5.1` | `haiku` / `opencode-go/qwen3.7-max` |
|
|
100
|
+
| **T3 Auditor** | `opus` *(must differ from T2)* | `opencode-go/deepseek-v4-pro` | `sonnet` / `opencode-go/kimi-k2.6` |
|
|
101
|
+
| **T4 Context-Ingest** | `sonnet` (long context) | `opencode-go/deepseek-v4-flash` | `opus` / `opencode-go/deepseek-v4-pro` |
|
|
102
|
+
| **T5 Fast-Cheap** | `haiku` | `opencode-go/deepseek-v4-flash` | `sonnet` / `opencode-go/mimo-v2.5` |
|
|
103
|
+
| **T6 Multimodal** | `sonnet` (vision) | `opencode-go/qwen3.7-max` *(weak — prefer Claude/Gemini)* | `opus` |
|
|
88
104
|
|
|
89
105
|
### Why these models
|
|
90
106
|
|
|
91
|
-
**Claude Code (
|
|
92
|
-
T1 (propose, specify reasoning) and T3 (validate, review)** — the two phases that
|
|
93
|
-
reasoning.
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
107
|
+
**Claude Code.** The top-family alias (`opus`) carries the tightest plan rate limits, so it is
|
|
108
|
+
**reserved for T1 (propose, specify reasoning) and T3 (validate, review)** — the two phases that
|
|
109
|
+
most reward deep reasoning. **`sonnet` is the workhorse** for coding (T2), large-context ingestion
|
|
110
|
+
(T4), and vision (T6). **`haiku`** handles fast/cheap formatting, orchestration, and summarization
|
|
111
|
+
(T5). This concentrates the scarce top-tier budget on architecture and audit and avoids exhausting
|
|
112
|
+
it during execution-heavy work. Because these are aliases, the mapping survives model generations
|
|
113
|
+
unchanged (e.g. when the top family moves from one generation to the next, `opus` follows it).
|
|
114
|
+
Users on plans that expose additional tiers (e.g. a Mythos-class model above Opus) can pin it for
|
|
115
|
+
T1/T3 in their project registry.
|
|
97
116
|
|
|
98
117
|
**OpenCode Go.** The two strongest open models anchor the two highest-leverage tiers:
|
|
99
118
|
|
|
@@ -115,20 +134,69 @@ exhausting it during execution-heavy work.
|
|
|
115
134
|
All OpenCode Go slugs are taken from the [OpenCode Go model list](https://opencode.ai/docs/go).
|
|
116
135
|
Confirm them against your own OpenCode configuration and adjust if your roster differs.
|
|
117
136
|
|
|
137
|
+
## Enforced routing (tool-native agent bindings)
|
|
138
|
+
|
|
139
|
+
The `/akili-execute` and `/akili-test` fan-out (Implementer, Reviewer, Testers) is where most
|
|
140
|
+
tokens are spent — and a generic subagent **inherits the session model**, which silently breaks
|
|
141
|
+
author ≠ auditor when the whole session runs on one model. Both tools support a `model` field on
|
|
142
|
+
**agent definitions** (never on commands), so `/akili-constitution` Step 8E binds the personas
|
|
143
|
+
there:
|
|
144
|
+
|
|
145
|
+
| Tool | Native agent location | Model value |
|
|
146
|
+
|---|---|---|
|
|
147
|
+
| Claude Code | `.claude/agents/akili-{leader,implementer,reviewer,tester}.md` (project-level) | Alias from the registry (`model: sonnet`, `model: opus`, `model: haiku`) |
|
|
148
|
+
| OpenCode | Project agent config (`.opencode/agent/*.md` or the `agent` block of `opencode.json`, per your OpenCode version) | Provider slug from the registry (`model: opencode-go/glm-5.1`) |
|
|
149
|
+
| Antigravity | Not supported — `invoke_subagent` has no per-agent model binding | Guidance-only fallback |
|
|
150
|
+
|
|
151
|
+
Each wrapper is thin: frontmatter (`name`, `description`, `model`) plus a body that instructs the
|
|
152
|
+
agent to read and fully adopt the corresponding `.agents/<role>.md` persona. The persona files in
|
|
153
|
+
`.agents/` remain the tool-agnostic source of truth; the wrappers only add the model binding.
|
|
154
|
+
`/akili-execute` and `/akili-test` prefer these named agents when they exist and fall back to
|
|
155
|
+
generic subagents seeded with the persona content when they don't.
|
|
156
|
+
|
|
157
|
+
**author ≠ auditor becomes structural:** `akili-reviewer` is pinned to a different model than
|
|
158
|
+
`akili-implementer` in the wrapper files themselves — no human discipline required.
|
|
159
|
+
|
|
160
|
+
## Model checkpoints (main loop)
|
|
161
|
+
|
|
162
|
+
The session model cannot be switched programmatically, but the agent knows which model it is
|
|
163
|
+
running on. Every AKILI command performs a one-line **model checkpoint** during setup: read the
|
|
164
|
+
project's `## Model Routing` registry, compare the phase's tier to the current session model, and
|
|
165
|
+
if they differ, tell the user in one line (e.g. *"This phase is T1 — the registry recommends
|
|
166
|
+
`/model opus`; you are on haiku"*) and offer the switch in the phase's first HITL pause. The user
|
|
167
|
+
can always continue on the current model; the checkpoint never blocks.
|
|
168
|
+
|
|
169
|
+
## Surviving model churn
|
|
170
|
+
|
|
171
|
+
Models change constantly; the design absorbs that at three layers:
|
|
172
|
+
|
|
173
|
+
1. **Tiers are the stable layer.** Phases map to T1–T6 and never change when models do.
|
|
174
|
+
2. **Aliases are the default.** The Claude column uses floating aliases that track the latest
|
|
175
|
+
generation automatically (see the alias-first rule above).
|
|
176
|
+
3. **Drift is detected, not discovered.** `/akili-audit` includes a **Model Registry Drift** check
|
|
177
|
+
(registry entries naming models the tool no longer offers, or a project registry older than the
|
|
178
|
+
packaged default), and `/akili-constitution` in Safe Update mode flags stale entries against the
|
|
179
|
+
packaged default without overwriting user pins. Each AKILI release refreshes this document's
|
|
180
|
+
default registry.
|
|
181
|
+
|
|
118
182
|
## How to apply per tool
|
|
119
183
|
|
|
120
|
-
- **Claude Code
|
|
184
|
+
- **Claude Code:** switch with `/model` before running a phase — e.g. `/model opus` for
|
|
121
185
|
`/akili-propose` and `/akili-validate`, `/model sonnet` for `/akili-execute` and `/akili-test`,
|
|
122
|
-
`/model haiku` for the tasks split and `/akili-archive
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
186
|
+
`/model haiku` for the tasks split and `/akili-archive` — or simply respond to each command's
|
|
187
|
+
model checkpoint. With Step 8E bindings in place, the execute/test triad routes itself
|
|
188
|
+
(Implementer on `sonnet`, Reviewer on `opus`).
|
|
189
|
+
- **OpenCode:** select the `opencode-go/...` model for each phase per the registry, or use the
|
|
190
|
+
Step 8E agent bindings. Keep the Reviewer/validator on a different model (`deepseek-v4-pro`)
|
|
191
|
+
than the Implementer (`glm-5.1`).
|
|
126
192
|
|
|
127
193
|
## Cross-tool safety
|
|
128
194
|
|
|
129
|
-
- **No `model:` frontmatter.** Command prompts stay `description:`-only. A single
|
|
130
|
-
cannot serve both tools anyway (Claude Code expects `opus`/`sonnet`/`haiku`;
|
|
131
|
-
`provider/model`), so model choice stays out of the prompts.
|
|
195
|
+
- **No `model:` frontmatter on commands.** Command prompts stay `description:`-only. A single
|
|
196
|
+
frontmatter value cannot serve both tools anyway (Claude Code expects `opus`/`sonnet`/`haiku`;
|
|
197
|
+
OpenCode expects `provider/model`), so model choice stays out of the prompts. Model bindings live
|
|
198
|
+
exclusively in **agent definitions**, which are per-tool, per-project files generated with the
|
|
199
|
+
user's approval in Step 8E.
|
|
132
200
|
- **No installer changes.** Nothing here is force-injected. `/akili-constitution` scaffolds a project
|
|
133
201
|
copy of this registry into `AGENTS.md` / `CLAUDE.md` as plain Markdown — identical handling across
|
|
134
202
|
Claude Code, OpenCode, and Google Antigravity.
|
package/docs/skills/README.md
CHANGED
|
@@ -20,6 +20,7 @@ The skill set is **curated, not accumulated**: every skill declares its original
|
|
|
20
20
|
| [`api-design-principles`](api-design-principles.md) | stack | Seth Hobson (MIT) | REST and GraphQL API design and review | Skill Map; constitution/specify stack lists |
|
|
21
21
|
| [`aws-serverless`](aws-serverless.md) | stack | vibeship (Apache-2.0) | Lambda, API Gateway, DynamoDB, SQS/SNS, SAM/CDK | Skill Map; constitution/specify stack lists |
|
|
22
22
|
| [`brainstorming`](brainstorming.md) | core | Jesse Vincent — obra (MIT) | Clarifying ideas, scope, options, and trade-offs before implementation | `/akili-constitution` Step 0, `/akili-propose`, `/akili-specify` phases 1–3 |
|
|
23
|
+
| [`caveman`](caveman.md) | core | Julius Brussee (MIT) | Token-economy compression of transient agent output (inter-agent messages `full`, progress lines `lite`) — never documents, HITL gates, or verbatim evidence | `/akili-execute` triad communication; `/akili-test` Leader↔Tester communication |
|
|
23
24
|
| [`cognitive-doc-design`](cognitive-doc-design.md) | core | gentleman-programming (Apache-2.0) | Human-facing docs that reduce cognitive load (lead with the answer, progressive disclosure, tables over prose) | `/akili-constitution`, `/akili-specify`, `/akili-execute` (PR docs), `/akili-archive` |
|
|
24
25
|
| [`error-handling-patterns`](error-handling-patterns.md) | stack | Seth Hobson (MIT) | Exceptions, Result patterns, graceful degradation, reliability | Skill Map; constitution/specify stack lists |
|
|
25
26
|
| [`frontend-design`](frontend-design.md) | conditional | Anthropic (Apache-2.0) | Distinctive frontend UI and UX implementation (fallback when `ui-ux-pro-max` is unavailable) | UI steps of `/akili-constitution`, `/akili-specify`, `/akili-test`, `/akili-validate`, `/akili-seo` |
|
|
@@ -31,6 +32,7 @@ The skill set is **curated, not accumulated**: every skill declares its original
|
|
|
31
32
|
| [`react-doctor`](react-doctor.md) | stack | Million.dev | React diagnostics after changes | Skill Map; `/akili-test`, `/akili-validate`, `/akili-execute` React work |
|
|
32
33
|
| [`seo-audit`](seo-audit.md) | core | Corey Haines (MIT) | Technical, on-page, and international SEO audits with a standard finding format | `/akili-seo` audit phase (required) |
|
|
33
34
|
| [`shadcn-ui`](shadcn-ui.md) | stack | community (origin unverified) | shadcn/ui components, forms, themes, Tailwind integration | Skill Map; constitution/specify stack lists; persona examples |
|
|
35
|
+
| [`software-architect`](software-architect.md) | core | Juan Carlos Cadavid — jcadavid.com (MIT) | Senior-architect Decision Spine: NFRs as measurable quality-attribute scenarios, tactics, robust-vs-lite tier sizing, architecture styles (hexagonal/clean/microservices), GoF pattern selection, C4 views + ADRs, agentic AI patterns | `/akili-constitution` Step 5 (required) and Step 6 tier handoff; `/akili-specify` Phase 2 for architecturally significant features |
|
|
34
36
|
| [`stitch-design`](stitch-design.md) | conditional | Google — google-labs-code | Stitch prompt enhancement and design generation workflows (fallback UI chain with `frontend-design`) | UI steps of `/akili-constitution`, `/akili-propose`, `/akili-specify` |
|
|
35
37
|
| [`systematic-debugging`](systematic-debugging.md) | core | Jesse Vincent — obra (MIT) | Root-cause investigation for bugs, test failures, unexpected behavior | `/akili-propose` Bug Track, `/akili-specify` Bug Mode, `/akili-test`, `/akili-validate`, `/akili-seo` |
|
|
36
38
|
| [`tailwind-design-system`](tailwind-design-system.md) | stack | Seth Hobson (MIT) | Tailwind CSS v4 tokens, component systems, responsive patterns | Skill Map; constitution/specify stack lists |
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
# `caveman`
|
|
2
|
+
|
|
3
|
+
**Author:** Julius Brussee — [github.com/juliusbrussee/caveman](https://github.com/juliusbrussee/caveman) (MIT)
|
|
4
|
+
**Adapted for AKILI-SPECS by:** Juan Carlos Cadavid — [jcadavid.com](https://jcadavid.com)
|
|
5
|
+
|
|
6
|
+
## Purpose
|
|
7
|
+
|
|
8
|
+
Ultra-compressed communication style (~65% fewer output tokens in upstream benchmarks): drop filler, keep substance, fragments OK, code and errors byte-for-byte exact. In AKILI it is the preventive tactic against output-token **MUDA** — scoped strictly to *transient* agent output, the chatter nobody rereads.
|
|
9
|
+
|
|
10
|
+
## The Scope Contract (the AKILI adaptation)
|
|
11
|
+
|
|
12
|
+
> `cognitive-doc-design` owns artifacts; `caveman` owns transient agent output.
|
|
13
|
+
|
|
14
|
+
| Output | Caveman |
|
|
15
|
+
|---|---|
|
|
16
|
+
| Inter-agent messages (Leader ↔ Implementer/Reviewer/Tester) | `full` |
|
|
17
|
+
| User-visible progress narration mid-run | `lite` |
|
|
18
|
+
| Persistent artifacts (PRD, TRD, specs, `execution.md`, `test-report.md`, PRs, Kaizen log) | off |
|
|
19
|
+
| HITL approval gates, Pivot blockers, `PRODUCT_BUG` escalations | off |
|
|
20
|
+
| Verbatim evidence: error strings, Reviewer FAIL reports, test output, code | never touched |
|
|
21
|
+
|
|
22
|
+
Upstream Auto-Clarity is preserved and extended: security warnings, irreversible-action confirmations, and every HITL pause drop compression automatically. When in doubt whether output is transient or persistent, treat it as persistent (off).
|
|
23
|
+
|
|
24
|
+
## Use When
|
|
25
|
+
|
|
26
|
+
- `/akili-execute` — automatic: inter-agent briefs/reports/feedback relays at `full`, progress lines at `lite`; the Structured Feedback rule wins (Reviewer reports pass unchanged).
|
|
27
|
+
- `/akili-test` — automatic: Leader→Tester slices and Tester structured reports at `full`.
|
|
28
|
+
- The user asks for token efficiency ("less tokens", "be brief", "caveman mode") in any context — respecting the Scope Contract.
|
|
29
|
+
|
|
30
|
+
## Best Paired Commands
|
|
31
|
+
|
|
32
|
+
- `/akili-execute`, `/akili-test` — where the multi-agent fan-out burns most output tokens.
|
|
33
|
+
- `kaizen` — compressed inter-agent chatter is measurable MUDA reduction; retrospectives may cite the savings.
|
|
34
|
+
|
|
35
|
+
## Source
|
|
36
|
+
|
|
37
|
+
- `../../.claude/skills/caveman/SKILL.md`
|
|
38
|
+
- Upstream: https://github.com/juliusbrussee/caveman
|
|
@@ -18,7 +18,7 @@ Every skill declares `metadata.binding` in its `SKILL.md` frontmatter. The bindi
|
|
|
18
18
|
|
|
19
19
|
| Binding | Skills |
|
|
20
20
|
|---|---|
|
|
21
|
-
| `core` | `kaizen` (archive), `judgment-day` (specify), `cognitive-doc-design` (all human-facing docs), `brainstorming` (constitution, propose), `product-manager-toolkit` (constitution), `systematic-debugging` (bug flows), `seo-audit` (seo) |
|
|
21
|
+
| `core` | `kaizen` (archive), `judgment-day` (specify), `cognitive-doc-design` (all human-facing docs), `brainstorming` (constitution, propose), `product-manager-toolkit` (constitution), `software-architect` (constitution TRD/infra, specify design), `caveman` (execute/test transient inter-agent output), `systematic-debugging` (bug flows), `seo-audit` (seo) |
|
|
22
22
|
| `conditional` | `ui-ux-pro-max`, `frontend-design`, `stitch-design` (UI work), `gsap-animation` (animation work) |
|
|
23
23
|
| `stack` | `angular-developer`, `nestjs-expert`, `shadcn-ui`, `tailwind-design-system`, `react-doctor`, `vercel-react-best-practices`, `aws-serverless`, `api-design-principles`, `error-handling-patterns` |
|
|
24
24
|
|
|
@@ -49,6 +49,8 @@ metadata:
|
|
|
49
49
|
|
|
50
50
|
Attribution is non-negotiable: MIT and Apache-2.0 licenses require preserving the original copyright and license notices. `adapted-by` records curation and AKILI adaptation — it never replaces the original `author`.
|
|
51
51
|
|
|
52
|
+
**Original-authorship variant:** skills authored originally for AKILI-SPECS (e.g. `kaizen`, `software-architect`) carry `author: Juan Carlos Cadavid — jcadavid.com` and may declare `inspired-by:` (a list of the works the method synthesizes) instead of `source`/`adapted-by`/`adapted-for` — there is no upstream to adapt from, but intellectual influences are still credited.
|
|
53
|
+
|
|
52
54
|
## Adaptation Levels
|
|
53
55
|
|
|
54
56
|
| Level | Who gets it | What it is |
|