acstack 0.50.3 → 0.51.0

package/skills/pre-commit-review/SKILL.md

@@ -59,7 +59,7 @@ git status --short
 git log --oneline -3  # recent context
 ```
 
-Read `acstack/project.yaml` to understand the project's directory layout, commands, and conventions.
+Read `.acstack/project.yaml` to understand the project's directory layout, commands, and conventions.
 
 Categorize changed files into scopes using the project configuration:
 
@@ -78,13 +78,15 @@ Follow the shared Implementation discipline in `orchestrator/AGENTS.md` for dele
 Investigate these dimensions directly or through useful delegation.
 Discover current conventions rather than hardcoding them.
 
+Read `../../output-styles/ac-writing-style.md` relative to this skill directory; apply its shared standard to code design as well as explanations.
+
 **Living specs and architecture:**
 
 ```
 Read the living specs relevant to this change:
-- Check acstack/specs/ directory listing
+- Check .acstack/specs/ directory listing
 - Read spec.md files for domains touched by the changed files
-  (use acstack/domain-map.yaml to map files -> domains)
+  (use .acstack/domain-map.yaml to map files -> domains)
 - Extract documented conventions, patterns, and requirements (FR-NNN entries)
 Report: list of project conventions and patterns relevant to these changes.
 ```
@@ -105,7 +107,7 @@ Report: established patterns, common approaches, naming conventions observed.
 ```
 For each changed file, read:
 - The full file (to see surrounding code context)
-- Import targets (what does this file import? read those files' signatures)
+- Connected callers and dependencies (read beyond signatures where needed to understand responsibilities and interface costs)
 - Config that governs this area (linter rules, compiler config, etc.)
 Report: local conventions, related code patterns, existing abstractions nearby.
 ```
@@ -137,14 +139,18 @@ For each finding, report:
 
 ```
 Examine the diff for:
-- Functions > 40 lines or > 3 levels of nesting
-- God functions doing too many things
-- Unclear variable/function names
-- Missing or premature abstractions
+- Tangled control flow, repeated decisions, or mixed responsibilities, with concrete evidence of the complexity
+- Incoherent boundaries or peer components at mismatched abstraction levels
+- Interfaces that expose internals instead of hiding real complexity behind small, useful operations (deep modules)
+- Names that misrepresent meaning, or structure driven by folder layout rather than responsibility
+- Missing useful boundaries or pass-through layers that add no useful boundary
 - Complex conditionals that could be simplified
 - Code that would be hard for a new developer to understand
 - Performance concerns (N+1 queries, unnecessary re-renders, blocking I/O)
 
+Do not require nesting or wrappers; neither line count nor indirection measures design quality.
+Support design findings with effects on connected callers and dependencies.
+
 For each finding, report:
   FILE:LINE | SEVERITY (MUST/SHOULD/CONSIDER) | WHAT | WHY | SUGGESTED FIX
 ```
@@ -175,7 +181,7 @@ Run the lint on the changed Markdown files, and on nothing else. Skip the comman
 
 The lint exits 0 even when it reports findings. It groups findings by file with line numbers, then prints a summary per file. It skips `skills/writing/vocabulary.md` on purpose.
 
-Add each finding to the review as `SHOULD | PROSE`, at the `file:line` it names. The writing standard is a project convention, so it sits at the same severity as other convention drift.
+Review each warning in context before treating it as a defect. Preserve necessary technical terms, quotations, and wording that would lose accuracy if changed. Report confirmed clarity or convention problems as `SHOULD | PROSE`, with the `file:line` and their effect on the reader.
 
 ## Step 4: ADJACENT – Check surrounding code for rot
 

package/skills/pre-commit-review/auto-fix.md

@@ -9,7 +9,7 @@ For each finding (MUST first, then SHOULD, then CONSIDER):
 3. If fix breaks something, revert and try alternate approach
 4. Move to next finding
 
-After all fixes, run full verification using commands from `acstack/project.yaml`:
+After all fixes, run full verification using commands from `.acstack/project.yaml`:
 
 ```bash
 # Run the project's configured test, lint, and typecheck commands

package/skills/quick-fix/SKILL.md

@@ -94,7 +94,7 @@ Apply the shared policy to the minimal fix.
 
 ## Step 6: Verify
 
-Run build verification using commands from `acstack/project.yaml`:
+Run build verification using commands from `.acstack/project.yaml`:
 
 ```bash
 # Run the project's configured test, lint, and typecheck commands

package/skills/record-context/SKILL.md

@@ -25,7 +25,7 @@ an obvious choice buries the ones that matter.
 
 ### Writing one
 
-- Path: `docs/adr/NNNN-slug.md`. The number is the highest existing number plus
+- Path: `.acstack/decisions/NNNN-slug.md`. The number is the highest existing number plus
   one, zero-padded to four digits. Create the directory lazily.
 
     If the file for that number appeared since you scanned (a parallel teammate
@@ -41,7 +41,7 @@ an obvious choice buries the ones that matter.
 
 ### Example
 
-`docs/adr/0004-invariant-tool-path.md`:
+`.acstack/decisions/0004-invariant-tool-path.md`:
 
 ```markdown
 # One invariant path for the command line tool
@@ -64,7 +64,7 @@ the hook has not run. The fix is to restart the agent session.
 
 ### You generate the index
 
-After writing any ADR, rewrite `docs/adr/index.md` in full, with one line
+After writing any ADR, rewrite `.acstack/decisions/index.md` in full, with one line
 per ADR. Sort the lines by number, ascending. Each line takes its number
 and slug from the filename, and its title from the file's first heading:
 
@@ -80,9 +80,9 @@ If you find hand edits in it, regenerate; the files are the truth.
 If the decision fixed what a word means – picked between competing names,
 sharpened a fuzzy term, coined one – record it:
 
-- **Cross-domain terms** go in `CONTEXT.md` at the repo root.
-- **Domain terms** go in `acstack/specs/<domain>/CONTEXT.md`, beside that
-  domain's `spec.md`. Find the domain in `acstack/domain-map.yaml`.
+- **Cross-domain terms** go in `.acstack/CONTEXT.md`.
+- **Domain terms** go in `.acstack/specs/<domain>/CONTEXT.md`, beside that
+  domain's `spec.md`. Find the domain in `.acstack/domain-map.yaml`.
 
 - Create both files lazily; there is no index file –
   `domain-map.yaml` already lists every domain.

package/skills/setup/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: setup
-description: Set up ACStack in a project, and change how an already configured project is set up. With no acstack/project.yaml it detects the project type, writes the config, generates the domain map and offers browser verification. With one already there it leads with the health check, then offers to fix each row that failed. Both paths end in the same check, so it is safe to run on the first day and on any day after.
+description: Set up ACStack in a project, and change how an already configured project is set up. With no .acstack/project.yaml it detects the project type, writes the config, generates the domain map and offers browser verification. With one already there it leads with the health check, then offers to fix each row that failed. Both paths end in the same check, so it is safe to run on the first day and on any day after.
 argument-hint: "[what to set up or change]"
 disable-model-invocation: true
 ---
@@ -18,7 +18,7 @@ join at the health check, so this skill states every fix once.
 
 ```mermaid
 flowchart TD
-    HOST["Step 1<br/>declare this machine"] --> FORK{"acstack/project.yaml<br/>is here?"}
+    HOST["Step 1<br/>declare this machine"] --> FORK{".acstack/project.yaml<br/>is here?"}
     FORK -- no --> FIRST["Steps 3 to 6<br/>detect, ask, write the config"]
     FORK -- yes --> CHECK
     FIRST --> CHECK["Step 7<br/>acstack config check --json"]
@@ -32,8 +32,8 @@ flowchart TD
 
 Three terms, before they get used:
 
-- A **health check** is one run of `acstack config check`. It audits the machine
-  and the project. It changes nothing.
+- A **health check** is one run of `acstack config check`. It reports gaps in the machine
+  and project configuration.
 
 - A **row** is one line of that report. It carries an `id`, a `status` and a
   `message`.
@@ -44,7 +44,6 @@ Three terms, before they get used:
 The command line tool audits. This skill interviews and writes. Neither one does
 the other's job.
 
-See `docs/adr/0008-cli-audits-skill-interviews.md`.
 
 ## Step 1: Declare this machine
 
@@ -75,8 +74,14 @@ answers. Come back to Step 2 when it finishes.
 
 ## Step 2: Choose the path
 
+Run `~/.claude/acstack/bin/acstack project-data ensure` before checking for configuration.
+It needs no config, does nothing without `.acstack/`, and preserves user tracking exceptions.
+
+If legacy project records remain, explain the explicit migration procedure in `docs/config-reference.md` before proceeding.
+Never move them silently or run Git index commands.
+
 ```bash
-test -f acstack/project.yaml && echo present || echo absent
+test -f .acstack/project.yaml && echo present || echo absent
 ```
 
 - **absent** – take the first-run path. Go to Step 3.
@@ -113,7 +118,7 @@ CLI. An agent testing this branch before the release runs
 It prints one object to standard output and nothing else:
 
 ```json
-{"checks": [{"id": "domain-map", "status": "pass", "message": "acstack/domain-map.yaml maps 4 domains"}]}
+{"checks": [{"id": "domain-map", "status": "pass", "message": ".acstack/domain-map.yaml maps 4 domains"}]}
 ```
 
 Each `status` is `pass`, `fail` or `info`. The exit codes carry the same news:
@@ -135,47 +140,7 @@ months ago deserves to hear what fails first.
 
 ## Step 8: Offer the rows that need a fix
 
-Build one multi-select question in the question tool (AskUserQuestion with
-`multiSelect: true` on Claude Code). Put one option in it per row you are going
-to offer, and say in each description what the row reported. This is the pre-selection the user sees: only real gaps reach the menu.
-
-Offer a row when any of these holds:
-
-- Its `status` is `fail`.
-- Its `id` is `preferred-browser-mode`, its `status` is `info`, and
-  `acstack/project.yaml` configures a `frontend` block. The project has a
-  frontend and has named no browser mode for it.
-
-- Its `id` is `output-style` and its `status` is `info`. The row passes when the
-  settings files select `acstack:ac-writing-style`, so `info` means they select
-  some other style, or select none.
-
-- Its `id` is `frontend-verification` and its `status` is `info`. The project
-  configures a frontend and `workflow.frontend_verification` is not `true`.
-
-Each of those rules reads the `status` and the `id`. Read neither row's message
-to decide, for the reason Step 7 gives: the message is prose and it gets
-reworded.
-
-Add three options at the end of the list, whatever the check reported:
-
-- **Re-declare this machine** – invoke the `host` skill. It re-asks every axis,
-  required and optional, and starts from the current answers.
-
-    The check reports an `optional-axis:<key>` row as `info`, never as `fail`.
-    So this option is the only way one of them reaches a question.
-
-- **Change one setting** – for a key the check has no opinion about, such as
-  `workflow.maps.persist`. Point the user at `docs/config-reference.md`, which
-  lists every key, its values and its default. Then write the key:
-
-  ```bash
-  ~/.claude/acstack/bin/acstack config set workflow.maps.persist true
-  ```
-
-  Do not restate the reference here.
-
-- **Skip** – leave everything as it is.
+Read [Step 8 in row-fixes.md](row-fixes.md#step-8-offer-the-rows-that-need-a-fix) and build its full menu.
 
 ## Step 9: Fix one row at a time
 
@@ -209,7 +174,7 @@ Read [`browser.md`](browser.md) when the user picks the remote mode in Step 10,
 
 ## Step 12: Offer the terminal workspace
 
-Read [`terminal-workspace.md`](terminal-workspace.md) on every run, after the rows are fixed.
+Read [`terminal-workspace.md`](terminal-workspace.md) on every run, after you fix the rows.
 
 ## Step 13: Offer the design review
 
@@ -235,7 +200,7 @@ Read [`report.md`](report.md) on every run, as the last step.
   It reads the key to decide which one.
 
     A `host.*` key goes to the global config at `~/.config/acstack/config.json`.
-    Every other key it knows goes to `acstack/project.yaml`, and the write keeps
+    Every other key it knows goes to `.acstack/project.yaml`, and the write keeps
     the comments and the key order. It refuses a key neither schema knows, so
     never fall back to editing the file.
 

package/skills/setup/browser.md

@@ -37,10 +37,10 @@ Write the answer as `remote`, `headless` or `local`. Write the port beside it:
 ~/.claude/acstack/bin/acstack config set frontend.browser.cdp_port 19988
 ```
 
-Then write `agent-browser.json` with the same port, the way Step 9c in `row-fixes.md` does.
+Then write `.acstack/agent-browser.json` with the same port, the way Step 9c in `row-fixes.md` does.
 
 On **Skip for now**, leave `frontend.browser` unset and write no
-`agent-browser.json`. Say that `docs/config-reference.md` documents the three
+`.acstack/agent-browser.json`. Say that `docs/config-reference.md` documents the three
 keys for later.
 
 On **Headless**, no setup follows. Tell the user the frontend verifier launches

package/skills/setup/first-run.md

@@ -1,9 +1,9 @@
 # Setup: first run
 
-`SKILL.md` decides when to read this file: Step 2 found no `acstack/project.yaml`, so the first-run path runs Steps 3 to 6 from here.
+`SKILL.md` decides when to read this file: Step 2 found no `.acstack/project.yaml`, so the first-run path runs Steps 3 to 6 from here.
 
-The file keeps its schema on both paths, so nothing migrates. `docs/config-reference.md`
-lists every key it can hold.
+First-run setup does not migrate legacy records; use the procedure in `docs/config-reference.md`.
+That reference also lists every configuration key.
 
 ## Step 3: Detect the project type and propose defaults
 
@@ -70,7 +70,7 @@ user did not select.
   Recommend `tool`. It writes `workflow.grilling.questions`.
 
 - Apply the shared Implementation discipline in `orchestrator/AGENTS.md` without adding workflow switches
-- Do not offer or generate the deprecated TDD booleans
+- Do not offer or generate the deprecated TDD booleans or retired `workflow.alignment_packs` settings
 
 
 - **Spec sync** – ask enabled against disabled.
@@ -81,12 +81,23 @@ paths reach Step 10 through the health check.
 
 ## Step 6: Write the config
 
-1. Create the `acstack/` directory.
-2. Write `acstack/project.yaml` from the profile and the answers.
-3. Leave the project CLAUDE.md alone. The SessionStart hook loads the
+1. Create the `.acstack/` directory.
+2. Immediately run `~/.claude/acstack/bin/acstack project-data ensure`, before writing any metadata.
+3. Write `.acstack/project.yaml` from the profile and the answers.
+4. Ask which project-data parts to track with a multi-select question, with nothing selected by default.
+   Offer the parts listed in `docs/config-reference.md` under "Project data stays local by default" in batches if the host limits options.
+   Include every part, not only the files setup creates today.
+5. Leave all parts ignored when the user selects none.
+6. Append native exceptions after existing root `.gitignore` rules, outside the managed baseline.
+    - When the user selects any part, append `!/.acstack/` once before that part's exceptions.
+    - A directory needs both `!/.acstack/specs/` and `!/.acstack/specs/**` (replace `specs` with the selected directory).
+    - A root-level file needs one exception, such as `!/.acstack/project.yaml`.
+    - Reopen parent directories before exceptions for nested files, such as `!/.acstack/verification/`.
+    - Preserve existing user rules; never force-add ignored files or change the Git index.
+7. Leave the project CLAUDE.md alone. The SessionStart hook loads the
    orchestrator instructions.
 
-4. Remove a legacy `@import` line from the project CLAUDE.md, if one is there.
+8. Remove a legacy `@import` line from the project CLAUDE.md, if one is there.
    It points at `.../plugins/cache/ac8318740-plugins/acstack/<version>/CLAUDE.md`.
 
 Then go to Step 7. Everything a fresh project still lacks shows up there as a

package/skills/setup/report.md

@@ -20,8 +20,9 @@ Browser:      [project's preferred mode / not configured]
 Design:       [on / off / not asked]
 Host:         [orchestrators + browser modes declared / not declared]
 Workspace:    [yes / yes, n updates available / not installed / declined / not asked]
-Config:       acstack/project.yaml
-Domain map:   acstack/domain-map.yaml ([n] domains / starter – fill in)
+Tracking:     [local only / user-selected parts via root .gitignore exceptions]
+Config:       .acstack/project.yaml
+Domain map:   .acstack/domain-map.yaml ([n] domains / starter – fill in)
 Output style: acstack:ac-writing-style (global) | (project) | not set
 
 Health check: [n] pass, [n] fail, [n] info

package/skills/setup/row-fixes.md

@@ -1,6 +1,52 @@
 # Setup: row fixes
 
-`SKILL.md` decides when to read this file: Step 9 is fixing a `browser-mode:<mode>`, `frontend-verification`, `domain-map`, `agent-browser`, `agent-browser-json`, `verification-knowledge` or `output-style` row.
+[The setup skill](SKILL.md) loads Step 8 on every run and Step 9 for the selected row fixes.
+
+## Step 8: Offer the rows that need a fix
+
+Build one multi-select question in the question tool (AskUserQuestion with
+`multiSelect: true` on Claude Code). Put one option in it per row you are going
+to offer, and say in each description what the row reported. This is the pre-selection the user sees: only real gaps reach the menu.
+
+Offer a row when any of these holds:
+
+- Its `status` is `fail`.
+- Its `id` is `preferred-browser-mode`, its `status` is `info`, and
+  `.acstack/project.yaml` configures a `frontend` block. The project has a
+  frontend and has named no browser mode for it.
+
+- Its `id` is `output-style` and its `status` is `info`. The row passes when the
+  settings files select `acstack:ac-writing-style`, so `info` means they select
+  some other style, or select none.
+
+- Its `id` is `frontend-verification` and its `status` is `info`. The project
+  configures a frontend and `workflow.frontend_verification` is not `true`.
+
+Each of those rules reads the `status` and the `id`. Read neither row's message
+to decide, for the reason Step 7 gives: the message is prose and it gets
+reworded.
+
+Add three options at the end of the list, whatever the check reported:
+
+- **Re-declare this machine** – invoke the `host` skill. It re-asks every axis,
+  required and optional, and starts from the current answers.
+
+    The check reports an `optional-axis:<key>` row as `info`, never as `fail`.
+    So this option is the only way one of them reaches a question.
+
+- **Change one setting** – for a key the check has no opinion about, such as
+  `workflow.maps.persist`. Point the user at `docs/config-reference.md`, which
+  lists every key, its values and its default. Then write the key:
+
+  ```bash
+  ~/.claude/acstack/bin/acstack config set workflow.maps.persist true
+  ```
+
+  Do not restate the reference here.
+
+- **Skip** – leave everything as it is.
+
+## Step 9: Fix one row at a time
 
 Five rows describe the machine: `required-axis`, `orchestrator`, `browser-mode`,
 `preferred-browser-mode` and `optional-axis`. Invoke the `host` skill for each of
@@ -45,7 +91,7 @@ frontend and has not turned browser verification on. Turn it on:
 
 ### 9a. Generate the domain map
 
-`acstack/domain-map.yaml` maps source paths to spec domains. Spec sync,
+`.acstack/domain-map.yaml` maps source paths to spec domains. Spec sync,
 `/acstack:archive`, `/acstack:bootstrap` and `/acstack:pre-commit-review` all
 read it. Without it, every path through spec sync skips in silence, and the
 living specs never update.
@@ -65,7 +111,7 @@ Guidance for the proposal:
 - Leave tests, config, build files and docs unmapped. Consumers skip a path that
   no domain covers.
 
-If `acstack/specs/` already holds domain directories, propose those names first
+If `.acstack/specs/` already holds domain directories, propose those names first
 and map the paths onto them. Renaming a domain here orphans its `spec.md`.
 
 Print the proposal and confirm it with the question tool (AskUserQuestion on Claude Code). Ask "Use this domain map,
@@ -97,23 +143,24 @@ with. Offer to install it:
 npm install -g agent-browser
 ```
 
-### 9c. Write agent-browser.json
+### 9c. Write the browser configuration
 
-This file tells `agent-browser` which port to dial. Write it in the project root:
+Create `.acstack/` if needed, then run `~/.claude/acstack/bin/acstack project-data ensure`.
+Write `.acstack/agent-browser.json` to name the CDP port:
 
 ```json
 {"cdp": "<cdp_port>"}
 ```
 
-Take `<cdp_port>` from `frontend.browser.cdp_port` in `acstack/project.yaml`. With
+Take `<cdp_port>` from `frontend.browser.cdp_port` in `.acstack/project.yaml`. With
 no value there, the default is `19988` under `mode: remote` and `9555` otherwise.
 The row fails when the two files name different ports, so change one of them.
 
 ### 9d. Create the knowledge base for verification
 
-The frontend verifier keeps what it learns in `VERIFICATION-KNOWLEDGE.md`, under
-the directory `frontend.helpers_dir` names. If that key states nothing, ask for a
-directory and write the key first. Then create the file:
+Create `.acstack/verification/VERIFICATION-KNOWLEDGE.md` for the frontend verifier.
+Keep helper programs in `frontend.helpers_dir`; do not move that directory or require it for metadata.
+Run `~/.claude/acstack/bin/acstack project-data ensure` after creating `.acstack/`, then write:
 
 ```markdown
 # Verification Knowledge Base

package/skills/sync/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sync
-description: Update living specs in acstack/specs/ from recent code changes. Called automatically by /commit for retroactive spec updates. Can also be invoked manually.
+description: Update living specs in .acstack/specs/ from recent code changes. Called automatically by /commit for retroactive spec updates. Can also be invoked manually.
 argument-hint: "[file-paths or 'staged']"
 ---
 
@@ -15,7 +15,7 @@ You **MUST** consider the user input before proceeding (if not empty).
 ## Purpose
 
 This skill analyzes code changes. It updates the cumulative living specs in
-`acstack/specs/` to reflect what changed. It is the "fast path" mechanism
+`.acstack/specs/` to reflect what changed. It is the "fast path" mechanism
 that keeps specs current even when a workflow skips full spec planning.
 
 ## Step 1: determine change scope
@@ -81,11 +81,11 @@ domain.
 5. Stage what `document` wrote
 
     `document` writes `DESIGN.md` and `.impeccable/design.json`. Stage both
-    with the commit, the same way this skill stages an updated spec file.
+    with the commit; stage updated specs only when the user opted into tracking them.
 
 ## Step 3: map changes to domains
 
-1. Read `acstack/domain-map.yaml`
+1. Read `.acstack/domain-map.yaml`
 2. Match changed files against domain path patterns
 3. Group changes by domain
 4. Skip files outside all domains (tests, config, docs)
@@ -96,7 +96,7 @@ If the diff affects no domains, report "No spec-relevant changes". Then exit.
 
 For each affected domain:
 
-1. Read `acstack/specs/[domain]/spec.md` (if it exists)
+1. Read `.acstack/specs/[domain]/spec.md` (if it exists)
 2. Analyze changes:
     - New functions/endpoints/components -> ADDED requirements
     - Modified signatures or behavior -> MODIFIED requirements
@@ -109,9 +109,9 @@ Write each functional requirement (FR) entry per the `writing` skill.
 ```markdown
 ### FR-014: The handoff anchor loads once
 
-- **Description**: The SessionStart hook injects `acstack/HANDOFF.md` after a
-  compaction, then moves the file into `acstack/handoffs/`.
-- **Behavior**: Given `acstack/HANDOFF.md` carries the `acstack_handoff`
+- **Description**: The SessionStart hook injects `.acstack/HANDOFF.md` after a
+  compaction, then moves the file into `.acstack/handoffs/`.
+- **Behavior**: Given `.acstack/HANDOFF.md` carries the `acstack_handoff`
   marker, When a session starts with source `compact`, Then the hook injects
   the file and retires it.
 - **Source**: `hooks/session-start-handoff.sh`
@@ -129,8 +129,8 @@ Write each merged FR per the `writing` skill.
 
 ## Step 6: glossary check
 
-Glossaries live in `CONTEXT.md` at the repo root (cross-domain terms) and
-`acstack/specs/[domain]/CONTEXT.md` (domain terms). If neither exists, skip.
+Glossaries live in `.acstack/CONTEXT.md` (cross-domain terms) and
+`.acstack/specs/[domain]/CONTEXT.md` (domain terms). If neither exists, skip.
 
 For each glossary term, check the diff. Look for a renamed or deleted
 identifier that matches it: function, class, table, config key, route. If
@@ -162,7 +162,8 @@ When `/commit` calls this skill:
 
 1. Receives the staged diff as context
 2. Runs silently (no user prompts)
-3. Returns a list of modified spec files for staging
+3. Returns modified specs for staging only when native `.gitignore` rules allow tracking
+    - Keep ignored specs updated locally; never force-add them or change the Git index to bypass the user's choice
 4. Adds `DESIGN.md` and `.impeccable/design.json` when Step 2 refreshed them
 5. Outputs minimal detail so it does not interrupt the commit flow
 

package/skills/terminal-workspace/SKILL.md

@@ -58,7 +58,7 @@ flowchart TD
 
 This is **machine-level, not per-project**. It installs binaries and writes
 keybindings for the user account, so it does not belong in
-`acstack/project.yaml`.
+`.acstack/project.yaml`.
 
 Count components when you mean config keys, and tools when you mean binaries.
 The config holds twelve component sections, plus an `enabled` master switch
@@ -79,6 +79,7 @@ The two files this skill works with:
 - **Config**: `~/.config/acstack/terminal-workspace.yaml`, copied from `assets/terminal-workspace/config.example.yaml`
 - **Script**: `assets/terminal-workspace/setup.sh` in this plugin
 
+Yazi's `i` opens Markdown in Frogmouth (`pipx install frogmouth`); existing `i` bindings take precedence, and `e` keeps editing in `$EDITOR`.
 The keys, on one page: [docs/terminal-workspace-keys.md](../../docs/terminal-workspace-keys.md).
 
 Background and why each piece is there:

package/skills/test-conventions/SKILL.md

@@ -7,7 +7,7 @@ description: Test placement rules and framework conventions. Invoke before writi
 
 ## Decision Tree: Where Does My Test Go?
 
-Read `acstack/project.yaml` for `directories.source`, `directories.tests`, and `frontend` config.
+Read `.acstack/project.yaml` for `directories.source`, `directories.tests`, and `frontend` config.
 
 ```
 Backend code?             → <tests-dir>/<mirror-source-path>/test_<module>.py
@@ -25,7 +25,7 @@ Mirror the source directory structure. Example: `src/auth/sessions.py` → `test
 - Shared fixtures → `<tests-dir>/conftest.py` (Python) or shared setup files
 - Use markers for slow/integration tests (configured in `test_markers.exclude`)
 - Run with the `commands.test` command from project.yaml
-- Baseline: `.test-baseline` – count must never drop
+- Baseline: `.acstack/.test-baseline` – count must never drop
 
 ## Layer 2: Frontend Unit Tests