macca-method 2.1.2 → 3.0.0-rc.1

package/.agents/skills/brainstorm-prd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: brainstorm-prd
-description: Interviews users and generates `PRD.md` with scope, outcomes, metrics, rollout, business rules, and traceability. Use only when the user explicitly wants to define a new product or create/recreate its PRD.
+description: Creates or updates `PRD.md` with scope, outcomes, metrics, rollout, business rules, and traceability. Use for explicit product/PRD planning, targeted completion/update user intent, or an authorized owner handoff, including spec-init Missing Decisions and approved technical sync.
 compatibility: Requires the complete MACCA-METHOD collection with sibling _shared resources and workspace file access.
 metadata:
   persona: "Galbi"
@@ -43,20 +43,20 @@ Before any interview:
 2. Read `../_shared/references/config-mutation.md`.
 3. Read `../_shared/references/brainstorm-session.md`.
 4. Read `../_shared/references/scope-rules.md`.
-5. Use `languagePreferences.communication.normalized` for chat.
-6. Use `languagePreferences.documents.normalized` for the final `project-context/PRD.md`.
+5. Use the resolved communication language from `language-config.md` for chat.
+6. Use the resolved document language from `language-config.md` for the final `project-context/PRD.md`.
 7. Apply `brainstormPreferences.discussionMode`, `recommendations`, and `discoveryDepth` using the shared session policy.
 
 ---
 
 ## How to Use This Skill
 
-1. Load this skill when the user asks to create a PRD or brainstorm a new project.
+1. Select the mode in `../_shared/references/brainstorm-session.md` before startup questions. Baseline-completion, targeted update, and approved technical sync take precedence over the new-document interview below.
 
 2. **Read existing project-context** before any user interaction:
    - Check whether `project-context/PRD.md` already exists to avoid duplication
 
-3. If `.agents/developer-config.json` exists, read `developerPreferences.scope`.
+3. Read the configured scope value from the safe preference summary under `language-config.md`.
    - `frontend` → PRD MUST focus on UI flows, pages, state, client validation, and backend/API dependencies
    - `backend` → PRD MUST focus on business rules, service/API/data/auth, and consumer dependencies
    - `fullstack` → full PRD
@@ -65,12 +65,16 @@ Before any interview:
 
 5. Run the interview in the chosen mode. Wait for the answer before continuing.
 
-6. After all topics, create `project-context/PRD.md`.
-
-   > ⚠️ **If the file already exists:** "(A) Overwrite all, (B) Cancel and review first." Wait for the answer.
+6. In new-document mode, complete applicable discovery and create `project-context/PRD.md`. For an existing file, follow the selected bounded mode; retain evidence, confidence, IDs, unrelated unknowns, and unrelated text. Regenerate only on an explicit request with approval of the named replacement.
 
 7. Summarize the PRD and suggest next steps based on scope.
 
+## Domain Applicability: Smallest Sufficient Product
+
+Apply the shared planning principles loaded by `brainstorm-session.md`. Define the smallest scope that fulfills approved current outcomes and security/recovery obligations, using evidence about expected usage, team, budget, and operations. Do not add admin panels, login, analytics, subscriptions, roles, or integrations merely because similar products have them. Critical depth means deeper discovery, not extra features.
+
+Keep acceptance criteria small, measurable, and tied to actual behavior. Do not invent SLOs or analytics infrastructure to make a template look complete; use existing/manual measurement when sufficient. Preserve required safeguards. Record user-mentioned future ideas as non-goals or unapproved possibilities, never as current requirements or implementation tasks. Unknown mandatory decisions remain open for approval, not `N/A`.
+
 ## Interview Topics (15 Topics)
 
 Ask the topics in order. Use conversational language.
@@ -91,9 +95,9 @@ _"Who are the target users? There may be multiple personas."_
 
 Collect:
 
-- User personas (Admin, Customer, Cashier, etc.)
-- Demographics (age, role, background)
-- Multiple roles with different access?
+- Actual users and needs supported by evidence
+- Relevant context/background only where it affects requirements
+- Distinct roles/access only if the approved workflows need them
 
 ### 3. Problem Statement
 
@@ -113,8 +117,8 @@ _"What are the main features?"_
 Collect:
 
 - MVP features (release 1)
-- Future enhancements
-- Priority of each
+- User-mentioned future possibilities, explicitly outside current approved scope
+- Priority of each approved feature
 
 ### 5. Business Rules
 
@@ -122,9 +126,9 @@ _"What business rules apply? For example: min/max values, pricing rules, special
 
 Collect:
 
-- Validation rules (for example password ≥ 8 characters)
-- Calculation rules (for example 10% member discount)
-- Access rules (for example only admins can delete)
+- Validation rules for actual inputs
+- Calculation rules for approved behavior
+- Access rules where restricted actions or data require them
 - Limits/thresholds
 
 ### 6. User Flow
@@ -168,10 +172,10 @@ _"What is the minimum definition of success for this project?"_
 Collect:
 
 - MVP criteria
-- Success metrics with baseline, target, timeframe, measurement source, and owner
+- Small measurable success criteria; baseline, target, timeframe, existing/manual measurement source, and owner where relevant
 - Timeline/deadline
 - Product rollout: pilot/beta/phased/full launch, target audience, and readiness criteria
-- Analytics events needed to measure the selected metrics, only when behavioral measurement is relevant
+- Analytics events only when approved measurement needs cannot be met sufficiently without them
 
 ### 10. Acceptance Criteria
 
@@ -210,7 +214,7 @@ Collect:
 
 - Stories per main feature
 - Ordered by priority
-- Example: "As an admin, I want to see the order list so I can process shipping"
+- Use only actual personas and approved features; a story does not authorize a new role or feature
 
 ### 14. Stakeholders
 
@@ -252,15 +256,9 @@ Adapt only sections that are applicable and preserve every required contract fro
 
 1. Confirm `project-context/PRD.md` was created successfully
 2. Summarize the PRD (2-3 sentences)
-3. Suggest the next workflow:
-   1. **`brainstorm-architecture`** ← required next
-   2. `brainstorm-schema` → after architecture (only if scope includes backend/data)
-   3. `brainstorm-api` → after schema or directly as a consumer contract (for frontend)
-   4. `brainstorm-styleguide` → optional after architecture, only if scope includes frontend/UI
-   5. `brainstorm-rules` → after API (or style guide)
-   6. `brainstorm-task` → final step before coding
-
-Each step can be skipped. Always confirm before proceeding.
+3. Recommend one next step using the applicability-aware priority in `brainstorm-session.md`: normally `brainstorm-architecture` after a new PRD. For a bounded update, return approved scope, IDs, changed sections, and evidence freshness to the caller instead of restarting planning.
+
+Only inapplicable inputs are `N/A`; do not bypass applicable prerequisites or start another skill without user intent or an authorized handoff.
 
 ## Important Notes
 

package/.agents/skills/brainstorm-prd/assets/PRD.template.md

@@ -1,5 +1,7 @@
 # PRD: [Project Name]
 
+> **Authoring note:** This is a placeholder menu, not a checklist to build. Use the smallest scope that fulfills approved current requirements and security/recovery obligations within evidenced scale, team, budget, and operational constraints. Prune inapplicable sections or mark `N/A` with a reason; unknown mandatory decisions remain open, not `N/A`. Do not infer login, admin, roles, subscriptions, analytics, or integrations from examples. Critical depth adds questions, not features. Use small measurable acceptance criteria and confirmed targets, not invented SLOs; future possibilities do not authorize requirements or tasks.
+
 > **Version:** 1.0 | **Date:** [date] | **Status:** Draft
 
 ## Document Role
@@ -24,7 +26,7 @@
 
 | Persona     | Description   | Role                   |
 | ----------- | ------------- | ---------------------- |
-| [Persona 1] | [Description] | End User / Admin / etc |
+| [Persona 1] | [Description] | [Actual role, if needed] |
 
 ## 3. Problem Statement
 
@@ -43,9 +45,9 @@
 | ------- | --------- | ------------- | -------- |
 | FEAT-01 | [Feature] | [Description] | High     |
 
-### Future Enhancements
+### User-Mentioned Future Possibilities (Not Approved Scope)
 
-- **FEAT-02:** [Feature] — [Description]
+- [Possibility explicitly raised by the user; exclude from current requirements and tasks until approved]
 
 ## 5. Business Rules
 
@@ -76,21 +78,20 @@
 
 | ID     | Category      | Requirement      | Target      |
 | ------ | ------------- | ---------------- | ----------- |
-| NFR-01 | Performance   | Page load time   | < 3 seconds |
-| NFR-02 | Security      | [Requirement]    | [Target]    |
-| NFR-03 | Scalability   | Concurrent users | [Count]     |
-| NFR-04 | Accessibility | [Requirement]    | [Target]    |
+| NFR-01 | [Applicable category] | [Approved requirement] | [Evidence-backed agreed target] |
+
+Record unresolved required targets as open decisions; retain applicable security, recovery, and accessibility obligations.
 
 ## 9. Success Metrics and Rollout
 
 | Metric   | Baseline          | Target   | Timeframe | Measurement Source | Owner   |
 | -------- | ----------------- | -------- | --------- | ------------------ | ------- |
-| [Metric] | [current/unknown] | [target] | [period]  | [analytics/report] | [owner] |
+| [Metric] | [current/unknown] | [target] | [period]  | [existing/manual source if sufficient] | [owner] |
 
 **Rollout:** [pilot / beta / phased / full]
 **Target Audience:** [initial cohort]
 **Readiness Criteria:** [conditions before expansion]
-**Analytics Events:** [only events required to measure the metrics]
+**Analytics Events:** [only if approved measurement cannot be met sufficiently with existing/manual sources]
 
 ## 10. Acceptance Criteria
 

package/.agents/skills/brainstorm-rules/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: brainstorm-rules
-description: Interviews users and generates `rules.md` for coding, security, dependency, testing, AI behavior, and conditional operational conventions. Use only when the user explicitly requests repository-wide implementation rules.
+description: Creates or updates `rules.md` for coding, security, dependency, testing, AI behavior, and conditional operational conventions. Use for repository-wide rules, targeted completion/update user intent, or an authorized owner handoff, including spec-init Missing Decisions, approved technical sync, and missing rules routed by implementation after applicable inputs are ready.
 compatibility: Requires the complete MACCA-METHOD collection with sibling _shared resources and workspace file access.
 metadata:
   persona: "Fachri"
@@ -37,13 +37,16 @@ This skill generates **rules.md**: a "code constitution" so AI works consistentl
 
 ## Usage
 
-1. Ideally run this before coding starts.
+1. Select the mode in `../_shared/references/brainstorm-session.md` before startup questions. Baseline-completion, targeted update, and approved technical sync take precedence over the new-document interview below. Run new rules discovery only after usable architecture and all applicable upstream inputs are ready, including persistence, API, and UI contracts. A missing `rules.md` does not bypass those prerequisites; route the first unmet applicable input to its owner. Implementation may hand off here automatically, but new rules still require applicable discovery and approval before writing.
 
 2. **Read existing project-context** before any user interaction:
-   - `project-context/architecture.md` — chosen tech stack and established patterns
-   - `project-context/PRD.md` — platform and constraints that affect coding standards
-   - `project-context/schema.md` — decisions about PII, retention, data protection
-   - `project-context/api.md` — auth contract, rate limiting, abuse controls
+   - `project-context/architecture.md` — required; chosen tech stack and established patterns
+   - `project-context/PRD.md` — required when available; platform and constraints that affect coding standards
+   - `project-context/schema.md` — only for backend/fullstack scope with persistence; decisions about PII, retention, and data protection
+   - `project-context/api.md` — only when the project exposes or consumes an API; auth contract, rate limiting, and abuse controls
+   - `project-context/StyleGuide.md` — only when frontend/UI rules apply
+
+   If a document is outside the declared scope or the project has no such contract, record it as `N/A`; do not treat it as a missing prerequisite.
 
 3. **Shared Runtime Setup** — before the interview (paths written as `../...` are relative to this SKILL.md's own folder, not the project's working directory):
 
@@ -51,19 +54,23 @@ This skill generates **rules.md**: a "code constitution" so AI works consistentl
 - Read `../_shared/references/config-mutation.md`.
 - Read `../_shared/references/brainstorm-session.md`.
 - Read `../_shared/references/scope-rules.md`.
-- Use `languagePreferences.communication.normalized` for chat.
-- Use `languagePreferences.documents.normalized` for the final `project-context/rules.md`.
+- Use the resolved communication language from `language-config.md` for chat.
+- Use the resolved document language from `language-config.md` for the final `project-context/rules.md`.
 - Apply `brainstormPreferences.discussionMode`, `recommendations`, and `discoveryDepth` using the shared session policy.
-- For this skill: announce that there are 7 topics, ask for pacing (one by one / three at once / all at once), and ask for recommendation preference if it is not already stored.
+- Use shared mode selection and setup only; reuse saved preferences and ask only missing preferences. Count remaining applicable topics rather than announcing a full interview for a bounded update.
 
 4. Run the interview in the selected mode. Wait for the answer before continuing.
 
-5. After all topics are complete, create `project-context/rules.md` (create `project-context/` if needed).
-
-   > ⚠️ **If the file already exists:** "(A) Overwrite all, (B) Cancel and review first." Wait for the answer.
+5. In new-document mode, complete applicable discovery, obtain approval, and create `project-context/rules.md` (create `project-context/` if needed). For an existing file, follow the selected bounded mode; retain evidence, confidence, IDs, unrelated unknowns, and unrelated text. Regenerate only on an explicit request with approval of the named replacement.
 
 6. Summarize the result and provide next steps.
 
+## Domain Applicability: Smallest Sufficient Rules
+
+Apply the shared planning principles loaded by `brainstorm-session.md`. Reuse mature approved conventions and native/existing tooling. Each rule should prevent a real project risk or support an approved requirement within the team's scale, budget, and operational capacity. New tools need evidence that simpler options are insufficient, implementation/maintenance cost, and a concrete escalation trigger.
+
+Do not impose universal strict mode, coverage percentages, naming schemes, frameworks, linters, or formatting tools. Match checks to the actual language and risk; record thresholds only when justified and approved. Critical depth means deeper questions about failure and enforcement, not more tooling. Preserve required security, data integrity/recovery, and accessibility safeguards. Unknown mandatory decisions remain open, not `N/A`.
+
 ## Interview Topics (7)
 
 ### 1. AI Persona & Tech Stack
@@ -72,10 +79,10 @@ This skill generates **rules.md**: a "code constitution" so AI works consistentl
 
 **Collect:**
 
-- List of technologies (for example TypeScript, React, Next.js 14, Prisma, PostgreSQL)
-- Prioritized libraries (for example TanStack Query, Zustand, React Hook Form, Zod)
-- Preferred patterns (for example functional components, Server Components, App Router)
-- Patterns to avoid (for example class components, Pages Router, `any` type)
+- Technologies and versions already approved in architecture
+- Existing libraries and conventions relevant to this repository
+- Patterns justified by actual responsibilities and team practices
+- Patterns to avoid only for a documented project reason
 
 ### 2. Naming Conventions
 
@@ -83,13 +90,9 @@ This skill generates **rules.md**: a "code constitution" so AI works consistentl
 
 **Collect:**
 
-- Variables & functions: camelCase
-- React components: PascalCase
-- Files & folders: kebab-case or camelCase?
-- Global constants: UPPER_CASE
-- Event handlers: `handle` prefix (for example `handleSubmit`, `handleClick`)
-- Boolean variables: `is/has/can` prefix (for example `isLoading`, `hasError`)
-- Database tables: snake_case, plural?
+- Existing language-native naming for symbols, files, and directories
+- UI/event-handler conventions only where those concepts exist
+- Datastore naming only when persistence is in scope
 
 ### 3. Code Style & Quality
 
@@ -97,13 +100,9 @@ This skill generates **rules.md**: a "code constitution" so AI works consistentl
 
 **Collect:**
 
-- TypeScript: strict mode? Avoid `any`? Avoid `enum` (use `as const`)?
-- `console.log`: forbidden in production?
-- Error handling: `try-catch` required? Prefer guard clauses (early return)?
-- Comments: JSDoc required? Minimal?
-- Maximum function length?
-- Preferred import order?
-- `else` after `return` — forbidden (prefer early return)?
+- Language-specific checks already used or justified by actual risk
+- Production diagnostics and error handling appropriate to the runtime
+- Comments, readability, and import conventions; numeric limits only if justified
 - Dependency decision ladder: reuse existing code → standard library → native platform → installed dependencies → new dependencies?
 - Intentional simplification: require a `tradeoff:` comment with ceiling and upgrade trigger?
 - What must never be simplified: trust-boundary validation, data-loss protection, accessibility basics, explicit requirements?
@@ -114,13 +113,13 @@ This skill generates **rules.md**: a "code constitution" so AI works consistentl
 
 **Collect:**
 
-- Token storage (httpOnly cookie, NOT localStorage)
-- User input sanitization before processing
-- Environment variable handling (do not hardcode, use `.env.example`)
-- SQL/query injection prevention (parameterized queries, ORM, no string concatenation)
-- XSS prevention (`dangerouslySetInnerHTML` policy?)
-- CORS: which origins are allowed?
-- Secret scanning: pre-commit hooks?
+- Credential/session protection appropriate to the approved authentication and platform
+- Untrusted-input validation and context-appropriate sanitization/encoding
+- Secret/configuration handling without hardcoded secrets; existing platform mechanisms first
+- Injection prevention for applicable query, shell, template, and parser boundaries
+- XSS prevention if rendering untrusted content
+- Cross-origin policy for applicable network surfaces
+- Secret scanning using existing tooling or justified additions
 - Align with decisions in `architecture.md`, `schema.md`, `api.md` — no contradictions.
 - If architecture defines observability: structured log levels, correlation IDs, redaction, sampling, and forbidden sensitive fields
 - If schema defines migrations: naming, compatibility, destructive-change approval, transaction/backfill, and validation conventions
@@ -156,16 +155,14 @@ This skill generates **rules.md**: a "code constitution" so AI works consistentl
 
 ### 7. Linter, Formatter & Testing
 
-**Ask:** _"What quality tools are used: ESLint, Prettier, test framework?"_
+**Ask:** _"Which quality checks already run, and which actual risks need additional verification?"_
 
 **Collect:**
 
-- ESLint: version? Rule set? (`eslint:recommended`, `@typescript-eslint/recommended`)
-- Prettier: options? (semicolon, quote style, print width)
-- `.editorconfig`: used?
-- Test framework: Jest, Vitest, Playwright?
-- Minimum coverage percentage?
-- Test requirement: mandatory for every new feature?
+- Existing linter, formatter, editor, and test configuration where applicable
+- Risk-based verification for changed behavior and critical paths
+- Coverage thresholds only if justified and approved; no universal minimum
+- Additional tools only where native/existing checks leave a demonstrated gap
 
 ## rules.md Output
 
@@ -179,7 +176,6 @@ Adapt only sections that are applicable and preserve every required contract fro
 
 After rules.md is complete:
 
-1. Run `brainstorm-task` to create Task.md from all spec documents
-2. Then: use the `developer` skill to start implementation
+Recommend one next step: normally `brainstorm-task` to derive work from the completed applicable specs. For bounded updates, return approved scope, IDs, changed sections, and evidence freshness to the caller; a rules update does not itself authorize implementation.
 
 ---

package/.agents/skills/brainstorm-rules/assets/rules.template.md

@@ -1,5 +1,7 @@
 # Coding Standards (Rules)
 
+> **Authoring note:** This is a placeholder menu, not a checklist to build. Keep rules justified by approved current requirements and real project risks; prune inapplicable sections or mark `N/A` with a reason. Unknown mandatory decisions remain open, not `N/A`. Reuse mature conventions and native/existing tooling. Do not impose universal strict mode, naming, coverage percentages, frameworks, or tools. New tooling needs a current requirement, why simpler options fail, cost within scale/team/budget/operations constraints, and an escalation trigger. Critical depth deepens questions; required security, integrity/recovery, and accessibility safeguards stay intact.
+
 ## Document Role
 
 - **Source of Truth:** Coding standards, AI behavior constraints, and implementation security rules
@@ -39,10 +41,10 @@
 - **Error Handling:** [stack-native strategy confirmed by the project]
 - **Control flow:** [confirmed readability rule]
 - **Import/dependency order:** [confirmed convention if applicable]
-- **Max function length:** [X lines]
-- **Comments:** [JSDoc required / minimal]
+- **Size limits:** [only if justified and approved]
+- **Comments:** [confirmed language-native documentation needs]
 - **Dependency ladder:** Reuse existing code first, then standard library, native platform, installed dependencies, and only then add new dependencies.
-- **Intentional simplification:** Mark with a `tradeoff:` comment that states the ceiling and upgrade trigger.
+- **Intentional simplification:** [agreed way to document material ceilings and upgrade triggers; no boilerplate comment for ordinary simple code]
 - **Never simplify:** trust-boundary validation, data-loss protection, accessibility basics, or explicitly requested behavior.
 
 Add a language-specific example only when it communicates a confirmed rule better than prose.
@@ -105,13 +107,11 @@ Add a language-specific example only when it communicates a confirmed rule bette
 | `perf:`     | Performance improvement                       |
 | `ci:`       | CI/CD config changes                          |
 
-**Example:** `feat(auth): add Google OAuth login`
+**Example:** [actual project change using the confirmed convention]
 
 **Branch naming:**
 
-- `feature/[feature-name]`
-- `fix/[bug-name]`
-- `chore/[task-name]`
+- [Existing/confirmed convention; no new branching scheme by default]
 
 ---
 
@@ -121,7 +121,7 @@ Add a language-specific example only when it communicates a confirmed rule bette
 - **Formatter:** [existing tool/options; omit if none].
 - **Editor settings:** [existing settings; omit if none].
 - **Test Framework:** [existing project framework]
-- **Minimum Coverage:** [X%]
+- **Coverage / Verification:** [risk-based checks; numeric threshold only if justified and approved]
 - **Test Requirement:** [project policy: test-first, test-with-change, or another explicit workflow].
 
 ---

package/.agents/skills/brainstorm-schema/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: brainstorm-schema
-description: Interviews users and generates `schema.md` for relational, document, key-value, graph, event-store, or mixed persistence, including evolution and recovery. Use only when the user explicitly requests data-model design after architecture.
+description: Creates or updates `schema.md` for relational, document, key-value, graph, event-store, or mixed persistence, including evolution and recovery. Use after applicable architecture decisions for explicit data-model planning, targeted completion/update user intent, or an authorized owner handoff, including spec-init Missing Decisions and approved technical sync.
 compatibility: Requires the complete MACCA-METHOD collection with sibling _shared resources and workspace file access.
 metadata:
   persona: "Fachri"
@@ -43,45 +43,49 @@ Before any interview:
 2. Read `../_shared/references/config-mutation.md`.
 3. Read `../_shared/references/brainstorm-session.md`.
 4. Read `../_shared/references/scope-rules.md`.
-5. Use `languagePreferences.communication.normalized` for chat.
-6. Use `languagePreferences.documents.normalized` for the final `project-context/schema.md`.
+5. Use the resolved communication language from `language-config.md` for chat.
+6. Use the resolved document language from `language-config.md` for the final `project-context/schema.md`.
 7. Apply `brainstormPreferences.discussionMode`, `recommendations`, and `discoveryDepth` using the shared session policy.
 
 ---
 
 ## How to Use This Skill
 
-1. Load after `architecture.md` is complete.
+1. Select the mode in `../_shared/references/brainstorm-session.md` before startup questions. Baseline-completion, targeted update, and approved technical sync take precedence over the new-document interview below. New schema planning follows usable architecture decisions and applies only to in-scope persistence; otherwise report schema as `N/A`.
 
 2. **Read existing project-context**:
    - `project-context/PRD.md` — features and business rules that determine tables
    - `project-context/architecture.md` — tech stack, ORM, database conventions
 
-3. If `.agents/developer-config.json` exists and `developerPreferences.scope = "frontend"`, DO NOT create `schema.md`. Explain that database and schema work is outside the current scope, and that backend dependencies should be documented only through the `api.md` consumer contract.
+3. If the configured scope value from the safe preference summary under `language-config.md` is `frontend`, DO NOT create `schema.md`. Explain that database and schema work is outside the current scope, and that backend dependencies should be documented only through the `api.md` consumer contract.
 
 4. Run the shared runtime setup above and apply all three pacing modes from the shared session policy. If preferences are saved, announce and proceed without another confirmation.
 
 5. Run the interview in the chosen mode. Wait for answers.
 
-6. After all topics, create `project-context/schema.md`.
-
-   > ⚠️ **If the file already exists:** "(A) Overwrite all, (B) Cancel and review first."
+6. In new-document mode, complete applicable discovery and create `project-context/schema.md`. For an existing file, follow the selected bounded mode; retain evidence, confidence, IDs, unrelated unknowns, and unrelated text. Regenerate only on an explicit request with approval of the named replacement.
 
 7. Summarize the result and suggest next steps.
 
+## Domain Applicability: Smallest Sufficient Data Model
+
+Apply the shared planning principles loaded by `brainstorm-session.md`. Reuse the approved datastore and native integrity facilities. Every entity, field, index, and projection must serve an approved current requirement, integrity obligation, or actual access pattern at the expected scale. New storage components need evidence that simpler options are insufficient, implementation/operating cost within team/budget constraints, and a concrete escalation trigger.
+
+Do not automatically add soft delete, version/history fields, tenant columns, event stores, or structures for future features. Use integrity constraints, transactions, concurrency protection, retention, and recovery where real data risks require them; simplicity does not justify data loss or weakened protection. Critical depth probes those risks more deeply without automatically adding infrastructure. Unknown mandatory decisions remain open rather than `N/A`.
+
 ## Interview Topics (5 Topics — All Required)
 
 Ask all five topics using the chosen pacing mode. First classify the persistence model from `architecture.md` as relational, document, key-value, graph, event store, or mixed. Adapt terminology and output to that model.
 
 ### 1. Database Conventions
 
-_"Before tables, let's align on conventions. Any preferences?"_
+_"Which conventions already apply to the selected datastore, and which current data requirements need a decision?"_
 
 Collect:
 
 - **Identity strategy:** primary key, document ID, aggregate/stream ID, graph ID, or key format?
 - **Naming:** datastore-native naming for tables, collections, keys, node labels, streams, and fields?
-- **Audit/version metadata:** timestamps, version/revision, event metadata, or none?
+- **Audit/version metadata:** only timestamps, revision, or event metadata required by current behavior, integrity, or audit obligations; otherwise none
 - **Deletion/retention:** hard delete, soft delete, tombstone, archival, compaction, or immutable events?
 - **Timestamp:** UTC or local timezone?
 - **Retention:** How long is data stored? Any anonymization or archival schedule?
@@ -125,7 +129,7 @@ Collect:
 - **Graph:** edge direction/cardinality and traversal boundaries
 - **Event store:** aggregate boundaries, stream correlation, projection consistency, and event evolution
 - **All modes:** delete/retention behavior and cross-structure consistency
-- Concurrency model: transaction boundary, optimistic version, lock/contention policy, duplicate update protection, or equivalent
+- Actual conflicting-write and duplicate-effect risks; use native transaction/constraint guarantees first, adding version/lock policies only where necessary
 
 ### 5. Indexes & Performance
 
@@ -134,7 +138,7 @@ _"Which access patterns, filters, sorts, traversals, stream reads, or lookups mu
 Collect:
 
 - Required reads/writes and expected scale
-- Datastore-native indexes, projections, partitioning, traversal, or caching needed for those access patterns
+- Datastore-native indexes needed for evidenced access patterns or integrity; projections, partitioning, and caching only for demonstrated needs
 - Consistency and latency expectations that constrain the design
 - Schema evolution: backward/forward compatibility, migration order, backfill, validation, rollback/roll-forward, and zero-downtime constraints when migrations apply
 
@@ -147,11 +151,7 @@ Adapt only sections that are applicable and preserve every required contract fro
 ## After schema.md Is Created
 
 1. Confirm the file was created successfully
-2. Suggest the next workflow:
-   1. **`brainstorm-api`** ← endpoints next
-   2. `brainstorm-styleguide` → optional if scope includes UI
-   3. `brainstorm-rules` → coding standards
-   4. `brainstorm-task` → work plan
+2. Recommend one next step using the applicability-aware priority in `brainstorm-session.md`: applicable unfinished API, then in-scope UI, then rules after all applicable inputs, then tasks. For bounded updates, return approved scope, IDs, changed sections, and evidence freshness to the caller.
 
 ## Important Notes
 

package/.agents/skills/brainstorm-schema/assets/schema.template.md

@@ -1,5 +1,7 @@
 # Database Schema
 
+> **Authoring note:** This is a placeholder menu, not a checklist to build. Keep entities, fields, indexes, and projections only for approved current requirements, integrity obligations, and actual access patterns. Prune inapplicable sections or mark `N/A` with a reason; unknown mandatory decisions remain open, not `N/A`. Reuse the approved datastore and native guarantees; no automatic soft delete, version/history, tenant columns, or future event store. New components need a current requirement, why simpler options fail, cost within scale/team/budget/operations constraints, and an escalation trigger. Critical depth deepens questions; preserve necessary integrity, concurrency, security, retention, and recovery protection.
+
 ## Document Role
 
 - **Source of Truth:** Data model and persistence contract
@@ -9,10 +11,10 @@
 ## Persistence Profile
 
 - **Model:** Relational / Document / Key-value / Graph / Event store / Mixed
-- **Identity Strategy:** [UUID / key format / aggregate ID / stream ID]
+- **Identity Strategy:** [selected datastore-native identity justified by current needs]
 - **Naming:** [datastore-native naming rules]
-- **Audit / Version Metadata:** [timestamps/version/event metadata]
-- **Deletion / Retention:** [soft delete / archival / tombstone / immutable event / retention policy]
+- **Audit / Version Metadata:** [only metadata required by current behavior, integrity, or audit obligations]
+- **Deletion / Retention:** [required deletion and retention behavior; no automatic soft delete/history]
 - **Timezone:** [UTC/local/N/A]
 
 ## Entity / Storage Map
@@ -25,18 +27,18 @@
 
 | Structure/Field | Category | Protection           | Retention        | Notes   |
 | --------------- | -------- | -------------------- | ---------------- | ------- |
-| [users.email]   | PII      | [encrypt/mask/plain] | [retention rule] | [notes] |
+| [actual field] | [sensitivity] | [required protection] | [retention rule] | [notes] |
 
 ## Scale, Tenancy & Concurrency
 
 - **Expected Scale/Growth:** [records, payload, growth]
 - **Tenant Isolation:** [N/A or enforcement model]
-- **Concurrency Strategy:** [transaction/version/lock/idempotency]
+- **Concurrency Strategy:** [actual conflicting-write/duplicate-effect risk and native guarantee; extra mechanisms only if needed]
 
 ## Schema Evolution & Migration
 
 - **Compatibility:** [backward/forward policy]
-- **Migration Order:** [expand/backfill/switch/contract or equivalent]
+- **Migration Order:** [steps required for actual data and compatibility constraints]
 - **Backfill & Validation:** [strategy]
 - **Failure Recovery:** [rollback or roll-forward]
 - **Zero-Downtime Constraint:** [if applicable]
@@ -53,7 +55,6 @@
 
 | Column   | Type   | Nullable | Default           | Constraint   | Notes   |
 | -------- | ------ | -------- | ----------------- | ------------ | ------- |
-| id       | UUID   | No       | gen_random_uuid() | PRIMARY KEY  |         |
 | [column] | [type] | [Yes/No] | [default]         | [constraint] | [notes] |
 
 **Relationships:**
@@ -62,7 +63,7 @@
 
 **Indexes:**
 
-- [column/index purpose]
+- [column/index, actual access pattern or integrity requirement, expected scale]
 
 ---