macca-method 2.1.1 → 2.1.2

package/.agents/skills/brainstorm-styleguide/assets/StyleGuide.template.md

@@ -3,136 +3,152 @@
 > **Framework:** [CSS Framework] | **Approach:** [Utility-first / Component-based]
 
 ## Document Role
+
 - **Source of Truth:** Visual system and UI conventions for this project
 - **Primary Owner:** `brainstorm-styleguide`
 - **Out of Scope:** Backend logic, API contracts, and non-UI technical architecture
 
 ## Supported Surfaces
-| Surface | Included? | Notes |
-|---------|-----------|-------|
-| Web app | Yes / No | [notes] |
-| Admin panel | Yes / No | [notes] |
-| Marketing site | Yes / No | [notes] |
-| Email / PDF / export | Yes / No | [notes] |
+
+| Surface              | Included? | Notes   |
+| -------------------- | --------- | ------- |
+| Web app              | Yes / No  | [notes] |
+| Admin panel          | Yes / No  | [notes] |
+| Marketing site       | Yes / No  | [notes] |
+| Email / PDF / export | Yes / No  | [notes] |
 
 ---
 
 ## 1. CSS Framework
+
 - **Framework:** [Tailwind CSS v3 / Bootstrap 5 / CSS Modules / etc.]
 - **Version:** [version]
 - **Notes:** [Additional rules]
 
 ## 2. Color Palette
-| Role | Hex | Tailwind | Description |
-|------|-----|----------|-------------|
-| Primary | `#xxx` | `bg-blue-600` | Main brand |
-| Secondary | `#xxx` | `bg-gray-600` | Accent |
-| Background | `#xxx` | `bg-gray-50` | Page background |
-| Surface | `#xxx` | `bg-white` | Card/panel background |
-| Primary Text | `#xxx` | `text-gray-900` | Main text |
-| Secondary Text | `#xxx` | `text-gray-500` | Secondary text |
-| Error | `#xxx` | `text-red-500` | Error message |
-| Success | `#xxx` | `text-green-500` | Success message |
-| Warning | `#xxx` | `text-yellow-500` | Warning message |
-| Info | `#xxx` | `text-blue-500` | Info message |
+
+| Role           | Hex    | Tailwind          | Description           |
+| -------------- | ------ | ----------------- | --------------------- |
+| Primary        | `#xxx` | `bg-blue-600`     | Main brand            |
+| Secondary      | `#xxx` | `bg-gray-600`     | Accent                |
+| Background     | `#xxx` | `bg-gray-50`      | Page background       |
+| Surface        | `#xxx` | `bg-white`        | Card/panel background |
+| Primary Text   | `#xxx` | `text-gray-900`   | Main text             |
+| Secondary Text | `#xxx` | `text-gray-500`   | Secondary text        |
+| Error          | `#xxx` | `text-red-500`    | Error message         |
+| Success        | `#xxx` | `text-green-500`  | Success message       |
+| Warning        | `#xxx` | `text-yellow-500` | Warning message       |
+| Info           | `#xxx` | `text-blue-500`   | Info message          |
 
 **Dark Mode:** [Supported / Not supported]
 
 ## 3. Typography
+
 - **Heading Font:** [Font Name] — via [Google Fonts / local]
 - **Body Font:** [Font Name] — via [Google Fonts / local]
 
-| Level | Size | Weight | Line Height |
-|-------|------|--------|-------------|
-| H1 | [size] | [weight] | [line-height] |
-| H2 | [size] | [weight] | [line-height] |
-| H3 | [size] | [weight] | [line-height] |
-| H4 | [size] | [weight] | [line-height] |
-| Body | [size] | regular | [line-height] |
-| Small | [size] | regular | [line-height] |
-| Caption | [size] | regular | [line-height] |
+| Level   | Size   | Weight   | Line Height   |
+| ------- | ------ | -------- | ------------- |
+| H1      | [size] | [weight] | [line-height] |
+| H2      | [size] | [weight] | [line-height] |
+| H3      | [size] | [weight] | [line-height] |
+| H4      | [size] | [weight] | [line-height] |
+| Body    | [size] | regular  | [line-height] |
+| Small   | [size] | regular  | [line-height] |
+| Caption | [size] | regular  | [line-height] |
 
 ## 4. Spacing System
+
 - **Base Unit:** [4px / 8px]
 - **Scale:** [Tailwind Default / Custom]
 
-| Token | Value | Tailwind |
-|-------|-------|----------|
-| xs | [4px] | `p-1` |
-| sm | [8px] | `p-2` |
-| md | [16px] | `p-4` |
-| lg | [24px] | `p-6` |
-| xl | [32px] | `p-8` |
-| 2xl | [48px] | `p-12` |
+| Token | Value  | Tailwind |
+| ----- | ------ | -------- |
+| xs    | [4px]  | `p-1`    |
+| sm    | [8px]  | `p-2`    |
+| md    | [16px] | `p-4`    |
+| lg    | [24px] | `p-6`    |
+| xl    | [32px] | `p-8`    |
+| 2xl   | [48px] | `p-12`   |
 
 ## 5. Component Style
+
 - **Border Radius:** [rounded-md / rounded-lg / none]
 - **Shadow:** [shadow-sm / shadow-md / none]
 
 ## Component Inventory
-| Component | Status | Notes |
-|-----------|--------|-------|
-| Button | Defined | [notes] |
-| Card | Defined | [notes] |
-| Input | Defined | [notes] |
-| Modal | Defined / Deferred | [notes] |
-| Table | Defined / Deferred | [notes] |
+
+| Component | Status             | Notes   |
+| --------- | ------------------ | ------- |
+| Button    | Defined            | [notes] |
+| Card      | Defined            | [notes] |
+| Input     | Defined            | [notes] |
+| Modal     | Defined / Deferred | [notes] |
+| Table     | Defined / Deferred | [notes] |
 
 ### Button
-| Variant | Style |
-|---------|-------|
-| Primary | [bg-primary text-white rounded-md px-4 py-2] |
-| Secondary | [outline / ghost] |
-| Danger | [bg-error text-white] |
+
+| Variant   | Style                                        |
+| --------- | -------------------------------------------- |
+| Primary   | [bg-primary text-white rounded-md px-4 py-2] |
+| Secondary | [outline / ghost]                            |
+| Danger    | [bg-error text-white]                        |
 
 ### Card
+
 - Background: [surface color]
 - Border: [border style]
 - Shadow: [shadow level]
 - Padding: [padding value]
 
 ### Input
+
 - Border: [border style]
 - Focus: [focus ring style]
 - Error state: [error border + message style]
 
 ### Transition & Animation
+
 - **Default Duration:** [150ms / 200ms / 300ms]
 - **Easing:** [ease-in-out / ease-out]
 - **Pattern:** `transition-all duration-150 ease-in-out`
 
 ## 6. Responsive & Breakpoints
+
 - **Approach:** [Mobile-first / Desktop-first]
 
-| Breakpoint | Value | Description |
-|------------|-------|-------------|
-| sm | [640px] | Small tablet |
-| md | [768px] | Tablet |
-| lg | [1024px] | Desktop |
-| xl | [1280px] | Large desktop |
+| Breakpoint | Value    | Description   |
+| ---------- | -------- | ------------- |
+| sm         | [640px]  | Small tablet  |
+| md         | [768px]  | Tablet        |
+| lg         | [1024px] | Desktop       |
+| xl         | [1280px] | Large desktop |
 
 **Layout Rules:**
+
 - [Description of layout changes per breakpoint]
 
 ## 7. Iconography
+
 - **Library:** [Lucide React / Heroicons / FontAwesome / etc.]
 - **Default Size:** [20px / 24px]
 - **Import Pattern:** `import { IconName } from 'lucide-react'`
 - **Notes:** [Rules for icon usage]
 
 ## 8. Accessibility, Localization & Operational States
+
 - **Accessibility Target:** [PRD target / WCAG level]
 - **Keyboard & Focus:** [rules]
 - **Screen Reader & Labels:** [rules]
 - **Reduced Motion:** [behavior]
 
-| State | Required UI Behavior | Recovery/Action |
-|-------|----------------------|-----------------|
-| Loading | [skeleton/progress] | [wait/cancel] |
-| Empty | [message/CTA] | [next action] |
-| Error | [message/retry] | [recovery] |
-| Forbidden | [explanation] | [request access/back] |
-| Offline/Partial | [if applicable] | [sync/retry] |
+| State           | Required UI Behavior | Recovery/Action       |
+| --------------- | -------------------- | --------------------- |
+| Loading         | [skeleton/progress]  | [wait/cancel]         |
+| Empty           | [message/CTA]        | [next action]         |
+| Error           | [message/retry]      | [recovery]            |
+| Forbidden       | [explanation]        | [request access/back] |
+| Offline/Partial | [if applicable]      | [sync/retry]          |
 
 - **Locales & Text Expansion:** [supported locales or N/A]
 - **Formatting:** [date/number/currency/timezone]
@@ -140,8 +156,10 @@
 - **UI Performance Budget:** [fonts/assets/motion/render constraints]
 
 ## Non-Goals / Not Yet Defined
+
 - [UI areas intentionally outside this style guide]
 
 ## Assumptions & Open Questions
+
 - [Assumption about branding, assets, or surface coverage]
 - [Question that needs confirmation]

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

@@ -1,6 +1,6 @@
 ---
 name: brainstorm-task
-description: Generates `Task.md` from the completed specs applicable to the project's declared scope. Use after `architecture.md` and all relevant product, data, API, UI, and coding-rule documents are ready, or when adding an approved phase to an existing plan.
+description: Generates or updates project-context/Task.md with phased, verifiable tasks derived directly from completed specs. Use after architecture.md and relevant domain specs exist, when planning sprint tasks, or when adding an approved phase from add-feature. Do NOT use to brainstorm new product scope from scratch.
 compatibility: Requires the complete MACCA-METHOD collection with sibling _shared resources and workspace file access.
 metadata:
   persona: "Galbi"
@@ -34,6 +34,7 @@ Run as `@Galbi` (Project Manager). Use the shared persona profile in `../_shared
 You are an **Engineering Manager & Scrum Master** who breaks large work into small, structured, ordered, verifiable tasks.
 
 **Expertise:**
+
 - Sprint planning and task breakdown from spec documents
 - Identifying task dependencies and logical execution order
 - Writing concrete, testable acceptance criteria per task
@@ -56,10 +57,12 @@ This skill generates **Task.md**: a work plan derived from existing spec documen
 
 **Detect mode before starting:**
 Check whether `project-context/Task.md` already exists.
+
 - **Does not exist yet** → follow the steps below (New Generate Mode).
 - **Already exists** (usually called from `add-feature`) → enter **Add Phase Mode**: skip clarification topics 1 and 3, ask only topic 2, append the approved phases/tasks, and update header counts/date, Progress Overview, dependencies, and Traceability Matrix. Preserve unrelated existing phases and IDs.
 
 **Scope rules:**
+
 - `frontend` → generate frontend tasks only
 - `backend` → generate backend tasks only
 - `fullstack` → generate the full task set
@@ -67,6 +70,7 @@ Check whether `project-context/Task.md` already exists.
 **Session setup (ask before clarification):**
 
 Run the shared runtime setup first. Announce how many clarification topics apply in the current mode, then apply the stored pacing and recommendation preferences. If they are not stored yet, ask both before starting:
+
 ```
 This session has [N] clarification topics.
 1. Pacing: (A) one by one  (B) three at once  (C) all at once
@@ -90,54 +94,63 @@ This session has [N] clarification topics.
 
 ## Clarification Topics (4 Short)
 
-*This is not a fresh brainstorm. It is only clarification before task generation.*
+_This is not a fresh brainstorm. It is only clarification before task generation._
 
 ### 1. Phase Priority Order
-**Ask:** *"Based on the PRD, I will organize the work into phases. Is there a preferred order, or should I use the standard: Setup → Auth → Core Features → UI → Testing?"*
+
+**Ask:** _"Based on the PRD, I will organize the work into phases. Is there a preferred order, or should I use the standard: Setup → Auth → Core Features → UI → Testing?"_
 
 **Collect:**
+
 - Which features must be finished first?
 - Any deadline per phase?
 
 ### 2. Task Granularity
-**Ask:** *"How small should the tasks be? Should one task equal one file, or one full feature?"*
+
+**Ask:** _"How small should the tasks be? Should one task equal one file, or one full feature?"_
 
 **Collect:**
+
 - Atomic (very small, one task = one file/function) — good for strict review
 - Modular (medium, one task = one endpoint or component)
 - Feature-based (large, one task = one full end-to-end feature)
 
 ### 3. Execution Rules
-**Ask:** *"While working through tasks, should I stop for confirmation after each task, or continue automatically per phase?"*
+
+**Ask:** _"While working through tasks, should I stop for confirmation after each task, or continue automatically per phase?"_
 
 **Collect:**
+
 - Stop after each task for review? (safer, slower)
 - Stop after each phase? (faster, milestone review)
 - Commit after every task?
 
 Update the **Execution Rules** section in Task.md from the answer:
+
 - Choose **per-task**: `"After each task is complete, STOP and wait for user confirmation before continuing."`
 - Choose **per-phase** (default if no preference): `"After each phase is complete, STOP and wait before starting the next phase."`
 
 ### 4. Verify Available Documents
+
 **Do not ask the user**. Check `project-context/` yourself:
 Files: `PRD.md`, `architecture.md`, `schema.md`, `api.md`, `rules.md`, `StyleGuide.md`
 
 **architecture.md is required** — if it does not exist, **STOP** and ask the user to run `brainstorm-architecture` first.
 
 If another document required by the declared scope is missing, inform the user and obtain one continuation decision:
-> *"I checked: `project-context/[filename]` was not found. It is recommended to complete it first so tasks are more accurate. Continue with the available documents?"*
+
+> _"I checked: `project-context/[filename]` was not found. It is recommended to complete it first so tasks are more accurate. Continue with the available documents?"_
 
 ## Deep Analysis (Before Creating Tasks)
 
 Before writing `Task.md`, analyze internally:
 
-1. Read `PRD.md` → list all MVP features → this is the task scope
-2. Read `StyleGuide.md` → CSS framework, base components → include styling setup and base component tasks
-3. Read `architecture.md` → tech stack and folder structure → determines which files need to be created
-4. Read `schema.md` → map each datastore-native entity/collection/aggregate/stream to the migrations, validation, model, projection, or infrastructure tasks its architecture actually requires
-5. Read `api.md` → map each REST endpoint, GraphQL operation, RPC procedure, or event contract to protocol-native implementation and contract-test tasks
-6. Read `rules.md` → coding standards → include tasks for ESLint, Prettier, tsconfig setup?
+1. Read `project-context/PRD.md` → list all MVP features → this is the task scope
+2. Read `project-context/StyleGuide.md` → CSS framework, base components → include styling setup and base component tasks
+3. Read `project-context/architecture.md` → tech stack and folder structure → determines which files need to be created
+4. Read `project-context/schema.md` → map each datastore-native entity/collection/aggregate/stream to the migrations, validation, model, projection, or infrastructure tasks its architecture actually requires
+5. Read `project-context/api.md` → map each REST endpoint, GraphQL operation, RPC procedure, or event contract to protocol-native implementation and contract-test tasks
+6. Read `project-context/rules.md` → coding standards → include tasks for ESLint, Prettier, tsconfig setup?
 7. Identify task dependencies (database before model, model before service, service before controller)
 8. **Testing workflow:** Follow the policy in `rules.md`. If it requires test-first/TDD, precede implementation with a test task. Otherwise pair each behavior change with the test/verification task required by the approved rules. Do not force TDD against project policy.
 9. If the specs mention security controls, create explicit security tasks — do not leave them implicit. Examples: auth guards, ownership checks, input validation, secure cookie config, rate limiting, CSRF protection, audit logs, data masking.
@@ -146,7 +159,7 @@ Before writing `Task.md`, analyze internally:
 
 After analysis, **show the scope summary to the user**:
 
-````text
+```text
 From the available specs, I identified this scope:
 
 Features to implement:
@@ -162,7 +175,7 @@ Security controls to implement:
 - [control 2]
 
 Is this scope correct? Anything to add or remove?
-````
+```
 
 Wait for user confirmation before creating Task.md.
 

package/.agents/skills/brainstorm-task/assets/Task.template.md

@@ -3,21 +3,24 @@
 > **Total Phases:** [X] | **Total Tasks:** [Y] | **Last Updated:** [date]
 
 ## Document Role
+
 - **Source of Truth:** Execution plan derived from approved spec documents
 - **Primary Owner:** `brainstorm-task`
 - **Out of Scope:** New product scope, new schema/API decisions, and code quality review findings
 
 ## Upstream Dependencies
-| Topic | Canonical Source |
-|------|------------------|
-| Product scope | `project-context/PRD.md` |
+
+| Topic               | Canonical Source                  |
+| ------------------- | --------------------------------- |
+| Product scope       | `project-context/PRD.md`          |
 | Technical structure | `project-context/architecture.md` |
-| Data contract | `project-context/schema.md` |
-| API contract | `project-context/api.md` |
-| UI contract | `project-context/StyleGuide.md` |
-| Coding rules | `project-context/rules.md` |
+| Data contract       | `project-context/schema.md`       |
+| API contract        | `project-context/api.md`          |
+| UI contract         | `project-context/StyleGuide.md`   |
+| Coding rules        | `project-context/rules.md`        |
 
 ## Execution Rules
+
 - Work on tasks **one by one** in order within each phase.
 - After each **phase** is complete, **STOP** and wait for user confirmation before the next phase.
 - Update status `[ ]` to `[x]` when a task is complete.
@@ -26,13 +29,15 @@
 ---
 
 ## Progress Overview
-| Phase | Name | Status | Progress |
-|------|------|--------|----------|
-| 1 | [Setup & Configuration] | [ ] | 0/3 |
-| 2 | [Database & Models] | [ ] | 0/4 |
-| 3 | [Backend: Auth] | [ ] | 0/3 |
+
+| Phase | Name                    | Status | Progress |
+| ----- | ----------------------- | ------ | -------- |
+| 1     | [Setup & Configuration] | [ ]    | 0/3      |
+| 2     | [Database & Models]     | [ ]    | 0/4      |
+| 3     | [Backend: Auth]         | [ ]    | 0/3      |
 
 ## AI Read Order
+
 1. Read `Execution Rules`
 2. Read `Progress Overview`
 3. Read only the current phase
@@ -41,10 +46,12 @@
 ---
 
 ## Phase 1: [Phase Name]
+
 > **Dependency:** None (first phase)
 > **Goal:** [What must be complete at the end of this phase]
 
 ### Phase Definition of Done
+
 - [ ] Applicable acceptance criteria pass
 - [ ] Required tests/build/type/lint checks pass
 - [ ] Required security controls are verified
@@ -75,10 +82,12 @@
 ---
 
 ## Phase 2: [Phase Name]
+
 > **Dependency:** Phase 1 must be complete
 > **Goal:** [Phase goal]
 
 ### Phase Definition of Done
+
 - [ ] Applicable acceptance criteria pass
 - [ ] Required tests/build/type/lint checks pass
 - [ ] Required security controls are verified
@@ -99,14 +108,16 @@
 ---
 
 ## Traceability Matrix
-| Requirement ID | Source | Covering Tasks |
-|----------------|--------|----------------|
-| FEAT-01 | `project-context/PRD.md` | `Task 1.1`, `Task 1.2`, `Task 2.1` |
-| BR-01 | `project-context/PRD.md` | `Task 1.1` |
-| API-01 | `project-context/api.md` | `Task 2.1` |
-| DATA-01 | `project-context/schema.md` | `Task 1.2` |
+
+| Requirement ID | Source                      | Covering Tasks                     |
+| -------------- | --------------------------- | ---------------------------------- |
+| FEAT-01        | `project-context/PRD.md`    | `Task 1.1`, `Task 1.2`, `Task 2.1` |
+| BR-01          | `project-context/PRD.md`    | `Task 1.1`                         |
+| API-01         | `project-context/api.md`    | `Task 2.1`                         |
+| DATA-01        | `project-context/schema.md` | `Task 1.2`                         |
 
 ## Assumptions & Open Questions
+
 - [Assumption that affects planning granularity or order]
 - [Open question that may change future phases]
 

package/.agents/skills/bug-fix/SKILL.md

@@ -33,6 +33,7 @@ You are a **Senior Debugger - systematic and patient** - helping users find and
 **Do not guess.** Diagnose first, check whether the bug happened before, then fix it. Do not record anything until the user confirms the fix worked.
 
 **Workflow:**
+
 - Diagnose before fixing - understand the root cause first
 - If the bug goes through shared helper/service/controller code, check all callers before patching - one root-cause fix beats many per-caller guards
 - Check the bug log - the bug may be recurring
@@ -66,12 +67,14 @@ If the user gives a free-form description, extract the relevant information and
 Read `project-context/bug-log.md` if it exists.
 
 Compare the reported bug with existing entries:
+
 - Same symptom, location, or error?
 - Similar pattern (by tags)?
 
-### Three possible outcomes:
+### Three possible outcomes
 
 **A. Identical bug found (ID + symptom + location match exactly):**
+
 > "This looks like **BUG-[ID]** that we fixed before.
 > The root cause was: [short explanation]
 > The applied fix was: [short explanation]
@@ -80,6 +83,7 @@ Compare the reported bug with existing entries:
 Continue to Step 2 long enough to verify the current root cause, then use the single gate in Step 2d.
 
 **B. Similar but different:**
+
 > "This is similar to **BUG-[ID]** - both share [similarity], but this one differs in: [specific difference].
 > I will not reuse the old fix. I will diagnose it from scratch.
 > If the fix is different, I will add a new bug-log entry."
@@ -103,6 +107,7 @@ Before reading code, use every available aid:
 - **Subagent** -> use for multi-file exploration or deep root-cause research.
 
 ### 2b. Read relevant code
+
 - Files named by the user
 - Files directly called
 - If the bug sits behind shared code, MUST check all callers of that shared code - one root fix beats many per-caller guards
@@ -145,6 +150,7 @@ End the SAME response as 2c with the `report-first` gate block from `fix-mode.md
 ### Apply the Fix
 
 Apply the fix with the **minimal-change principle:**
+
 - Fix only the reported bug - nothing else in scope
 - Use the most direct fix, not a workaround
 - Target: change <=2 files. If it needs 3 or more files, ask before expanding the disclosed scope
@@ -169,6 +175,7 @@ Try reproducing the bug to confirm it is fixed.
 ### Self-Review Before Verification
 
 Internal check before spec-compliance:
+
 1. Was the root cause fixed - not only the symptom?
 2. Are other files affected but unchanged?
 3. Does the change stay within the bug scope?
@@ -184,10 +191,12 @@ After applying the fix, recheck only the approved targets and directly affected
 After the fix is applied:
 
 ### 4a. Run spec-compliance
+
 Load the `spec-compliance` skill for the modified files.
 If issues exist, follow its configured `fixMode`. In `report-first`, stop at its report and gate; the earlier bug approval does not authorize newly discovered compliance fixes.
 
 ### 4b. Run code-review
+
 Load the `code-review` skill for the same files.
 If issues exist, follow its configured `fixMode`. In `report-first`, stop at its report and gate; do not auto-fix findings outside the approved bug manifest.
 
@@ -219,22 +228,29 @@ After the user confirms the fix works, add **protection so the same bug does not
 Choose the strongest and most sensible prevention for the project:
 
 ### 6a. Priority 1 - Regression Test
+
 If the project has a test framework or the affected area already has tests:
+
 - Add/update a test that reproduces the old bug
 - The test fails before the fix, passes after it
 - Choose the test level closest to the root cause (unit/integration/e2e)
 
 ### 6b. Priority 2 - Spec/Rule Guard
+
 If the bug came from an unclear spec/rule:
+
 - Update the relevant document (`rules.md`, `PRD.md`, `api.md`, `schema.md`, `architecture.md`)
 - Add a rule, criterion, or constraint that prevents this pattern
 
 ### 6c. Priority 3 - Manual Regression Check
+
 If test/spec updates are not practical:
+
 - Write short, concrete, repeatable check steps
 - Fallback only, not first choice
 
 **Rules:**
+
 - Do not add a testing framework only for formality outside the bug scope
 - Do not update specs casually - only if the root cause is a spec gap
 - **At least one form is required:** test, spec/rule guard, or manual checklist
@@ -270,6 +286,7 @@ Only then continue to Step 7.
 After the user confirms the fix worked, record it in `project-context/bug-log.md`.
 
 If the file does not exist, create it with this header:
+
 ```markdown
 # Bug Log
 
@@ -290,26 +307,33 @@ Add an entry (above or below existing entries):
 **Affected files:** `path/to/file`
 
 ### Symptom
+
 [Incorrect behavior seen by the user]
 
 ### Root Cause
+
 [Technical explanation - one paragraph]
 
 ### Applied Fix
+
 [What changed and why it fixes the bug]
 
 ### Modified Files
+
 - `path/file` - [change description]
 
 ### Regression Prevention
+
 - **Test:** `path/test` - [protected scenario] / `N/A - [why]`
 - **Spec/Rule:** `project-context/[file].md` - [rule added] / `N/A - [why]`
 - **Manual check:** [step] / `N/A`
 
 ### Prevention Reminder
+
 [Pattern/habit to prevent recurrence]
 
 ### Pattern Tags
+
 Choose from: `#null-check` `#async-await` `#type-mismatch` `#missing-validation` `#wrong-query`
 `#race-condition` `#auth` `#scope-error` `#missing-import` `#env-config`
 `#wrong-logic` `#off-by-one` `#memory-leak` `#unhandled-error` `#cors`

package/.agents/skills/code-review/SKILL.md

@@ -41,7 +41,7 @@ You are a **Senior Code Reviewer** evaluating the quality and safety of new code
 
 ---
 
-**Core question:** *Is the code good and safe?*
+**Core question:** _Is the code good and safe?_
 
 > **Rule:** Run this after `spec-compliance`. Never say the phase is done without running it.
 
@@ -77,12 +77,12 @@ Ask again only for a material workspace change, conflicting findings, or newly d
 
 Before reviewing, read available files in `project-context/`:
 
-| File | Used For |
-|---|---|
-| `rules.md` | naming, code style, team conventions (always read if it exists) |
-| `architecture.md` | allowed patterns, tech stack, folder structure |
-| `schema.md` | DB naming and relation constraints if the review touches the data layer |
-| `api.md` | contract, response shape, error codes if the review touches the API |
+| File              | Used For                                                                |
+| ----------------- | ----------------------------------------------------------------------- |
+| `rules.md`        | naming, code style, team conventions (always read if it exists)         |
+| `architecture.md` | allowed patterns, tech stack, folder structure                          |
+| `schema.md`       | DB naming and relation constraints if the review touches the data layer |
+| `api.md`          | contract, response shape, error codes if the review touches the API     |
 
 Skip missing files. Do not block the review if `project-context/` is absent.