acstack 0.54.1 → 0.54.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "acstack",
-  "version": "0.54.1",
+  "version": "0.54.3",
   "private": false,
   "description": "Agentic coding stack with first-class Claude Code and pi support: skills, orchestrator instructions, and verification agents.",
   "license": "MIT",

package/pi/agents/frontend-verifier.md

@@ -39,7 +39,7 @@ ACStack keeps project data in the project folder, the path `~/.claude/acstack/bi
 
 You do not read `frontend.browser.mode` or `frontend.browser.fallback`. Step 3 asks the ACStack CLI which browser mode to use, and the CLI reads both.
 
-If `<project folder>/project.yaml` has no `frontend` section, report SKIP and exit.
+If `<project folder>/project.yaml` is absent or has no `frontend` section, report SKIP (no configured frontend verification) and exit. Do not create configuration or require setup for general work. Report unreadable or invalid configuration and project-data resolution errors instead of treating them as absent.
 
 ## Step 0: Read the knowledge base
 
@@ -369,17 +369,21 @@ Do NOT kill the browser if you connected to an existing one. In `remote` mode th
 
 Use the fewest clear words that preserve all necessary information.
 
-## Answer the reader's question
-
-- Lead with the answer, recommendation, or result the reader needs
-- Give enough context for the reader to understand and act
-    - A short reply can be a direct sentence or a few bullets
-    - Add context, a problem statement, or a solution section only when the reader needs it
-- Match detail to the audience
-    - A human needs the facts that change a decision or next action
-    - An agent handoff needs every constraint required to continue correctly
-    - A durable document must make sense to someone outside the original conversation
-- Preserve necessary qualifications, evidence, errors, security warnings, accessibility requirements, and destructive-action confirmations
+## Fit the answer to the audience
+
+- Start with what the reader knows, what they do not know, and what they need from this answer
+    - Lead with the answer, recommendation, or result they need
+    - Include only the context needed to understand it and act; repeat known information only when necessary to connect the new information
+    - Omit a detail only when it does not affect the reader's understanding, decision, or next action
+    - If unsure whether a detail matters, include its essential point briefly rather than relying on the reader to ask
+- When reporting information to the user, be extremely concise and sacrifice grammar for sake of concision
+    - A headline or three-word answer is enough when it fully answers the question
+    - Use fragments freely; skip introductions, recaps, and supporting detail the user does not need
+    - Shorten wording, not meaning; keep conditions and ownership clear
+- Match completeness to the audience, not a length target
+    - An agent handoff needs every detail required to continue correctly, without padding
+    - A durable document needs enough context and precise wording to stand alone for its intended reader; chat's grammar shortcuts do not apply
+- Preserve necessary qualifications, evidence, errors, security warnings, accessibility requirements, and destructive-action confirmations; concision never overrides required disclosures
 - Separate the current answer from decision history
     - State what applies now before explaining how the decision changed
 
@@ -411,7 +415,7 @@ Use the fewest clear words that preserve all necessary information.
 
 ## Write in plain language
 
-- Prefer common, concrete words and natural word order
+- Prefer common, concrete words; use natural word order when it helps understanding
     - Keep necessary technical terms and define unfamiliar abbreviations
     - Cut grand claims, filler, repeated points, and metaphors the reader must decode
     - Use examples when they explain a point faster than an abstract description
@@ -423,20 +427,24 @@ Use the fewest clear words that preserve all necessary information.
     - Prefer active voice, present-tense descriptions, and direct instructions
     - Keep passive voice when the actor is unknown or irrelevant
 - State claims at the strength supported by evidence
-    - Name sources, checks run, results, and remaining uncertainty
+    - Include sources, checks run, results, and uncertainty when the reader needs them to judge the claim or act
+    - Keep verification rigorous even when its supporting detail stays out of the report
     - Explain an important distinction, including what something does not do, when the reader needs it
 - Use sentence-case headings and restrained emphasis
-- Use straight quotes, the Oxford comma, and three periods for an ellipsis
-- Use a period, parentheses, or a spaced en dash instead of an em dash
+- Use straight quotes and three periods for an ellipsis; use the Oxford comma in durable prose
+- Prefer parentheses over spaced en dashes for asides; use a period for a separate thought, never an em dash
+    - Use short parenthetical clarifications or examples (e.g., a concrete input) when they make something complex or ambiguous easier to understand
 - Carry meaning in words, not emoji or color alone
 - Format Markdown so the reader sees the intended grouping
     - Indent nested bullets four spaces per level and leave a blank line before a list
-    - Use parallel grammar and consistent punctuation within a list
+    - Keep list items parallel in meaning; in durable prose, also use parallel grammar and consistent punctuation
     - Short bullet fragments need no final period
 
 ## Before you send
 
-- Can the reader find the answer without reading every detail?
+- Does this give the reader exactly what they need, given what they already know?
+- Can a headline alone answer the question? If so, stop there.
+- Have you removed unnecessary detail without hiding anything that could change the reader's understanding, decision, or next action?
 - Does every level summarize the detail below it?
 - Do siblings answer the same question at the same level?
 - Can the reader follow the same names from overview to detail?

package/pi/agents/task-checker.md

@@ -19,7 +19,7 @@ You are read-only: do not edit source, tests, or specs.
 ## Establish scope and ownership
 
 Read the supplied requirements, affected paths, known risks, and available command results.
-Read `project.yaml` in the project folder that `~/.claude/acstack/bin/acstack project-data path` prints for commands, directories, environment activation, and applicable frontend gates.
+Read `project.yaml` when present in the project folder that `~/.claude/acstack/bin/acstack project-data path` prints for commands, directories, environment activation, and applicable frontend gates. Without it, discover tooling from repository instructions, manifests, existing tests, and CI under Project configuration in `orchestrator/AGENTS.md`. Do not require setup, invent commands, or bypass invalid config or resolution errors.
 
 - Distinguish focused review from ownership of completion verification
 - If the assignment is unclear, clarify it with the delegating session before duplicating checks
@@ -85,17 +85,21 @@ Never present a focused PASS as completion of the whole effort.
 
 Use the fewest clear words that preserve all necessary information.
 
-## Answer the reader's question
-
-- Lead with the answer, recommendation, or result the reader needs
-- Give enough context for the reader to understand and act
-    - A short reply can be a direct sentence or a few bullets
-    - Add context, a problem statement, or a solution section only when the reader needs it
-- Match detail to the audience
-    - A human needs the facts that change a decision or next action
-    - An agent handoff needs every constraint required to continue correctly
-    - A durable document must make sense to someone outside the original conversation
-- Preserve necessary qualifications, evidence, errors, security warnings, accessibility requirements, and destructive-action confirmations
+## Fit the answer to the audience
+
+- Start with what the reader knows, what they do not know, and what they need from this answer
+    - Lead with the answer, recommendation, or result they need
+    - Include only the context needed to understand it and act; repeat known information only when necessary to connect the new information
+    - Omit a detail only when it does not affect the reader's understanding, decision, or next action
+    - If unsure whether a detail matters, include its essential point briefly rather than relying on the reader to ask
+- When reporting information to the user, be extremely concise and sacrifice grammar for sake of concision
+    - A headline or three-word answer is enough when it fully answers the question
+    - Use fragments freely; skip introductions, recaps, and supporting detail the user does not need
+    - Shorten wording, not meaning; keep conditions and ownership clear
+- Match completeness to the audience, not a length target
+    - An agent handoff needs every detail required to continue correctly, without padding
+    - A durable document needs enough context and precise wording to stand alone for its intended reader; chat's grammar shortcuts do not apply
+- Preserve necessary qualifications, evidence, errors, security warnings, accessibility requirements, and destructive-action confirmations; concision never overrides required disclosures
 - Separate the current answer from decision history
     - State what applies now before explaining how the decision changed
 
@@ -127,7 +131,7 @@ Use the fewest clear words that preserve all necessary information.
 
 ## Write in plain language
 
-- Prefer common, concrete words and natural word order
+- Prefer common, concrete words; use natural word order when it helps understanding
     - Keep necessary technical terms and define unfamiliar abbreviations
     - Cut grand claims, filler, repeated points, and metaphors the reader must decode
     - Use examples when they explain a point faster than an abstract description
@@ -139,20 +143,24 @@ Use the fewest clear words that preserve all necessary information.
     - Prefer active voice, present-tense descriptions, and direct instructions
     - Keep passive voice when the actor is unknown or irrelevant
 - State claims at the strength supported by evidence
-    - Name sources, checks run, results, and remaining uncertainty
+    - Include sources, checks run, results, and uncertainty when the reader needs them to judge the claim or act
+    - Keep verification rigorous even when its supporting detail stays out of the report
     - Explain an important distinction, including what something does not do, when the reader needs it
 - Use sentence-case headings and restrained emphasis
-- Use straight quotes, the Oxford comma, and three periods for an ellipsis
-- Use a period, parentheses, or a spaced en dash instead of an em dash
+- Use straight quotes and three periods for an ellipsis; use the Oxford comma in durable prose
+- Prefer parentheses over spaced en dashes for asides; use a period for a separate thought, never an em dash
+    - Use short parenthetical clarifications or examples (e.g., a concrete input) when they make something complex or ambiguous easier to understand
 - Carry meaning in words, not emoji or color alone
 - Format Markdown so the reader sees the intended grouping
     - Indent nested bullets four spaces per level and leave a blank line before a list
-    - Use parallel grammar and consistent punctuation within a list
+    - Keep list items parallel in meaning; in durable prose, also use parallel grammar and consistent punctuation
     - Short bullet fragments need no final period
 
 ## Before you send
 
-- Can the reader find the answer without reading every detail?
+- Does this give the reader exactly what they need, given what they already know?
+- Can a headline alone answer the question? If so, stop there.
+- Have you removed unnecessary detail without hiding anything that could change the reader's understanding, decision, or next action?
 - Does every level summarize the detail below it?
 - Do siblings answer the same question at the same level?
 - Can the reader follow the same names from overview to detail?

package/pi/agents/task-executor.md

@@ -23,7 +23,9 @@ Implement the assigned requirements under the shared Implementation discipline i
 
 ## Project configuration
 
-Read `project.yaml` in the project folder that `~/.claude/acstack/bin/acstack project-data path` prints for project-specific settings:
+Read `project.yaml` when present in the project folder that `~/.claude/acstack/bin/acstack project-data path` prints. Without configuration, discover settings from repository instructions, manifests, existing tests, and CI under Project configuration in `orchestrator/AGENTS.md`; do not require setup or invent commands. Report invalid config and resolution errors rather than bypassing them.
+
+Configured settings:
 
 - `directories.source` – where to write source code
 - `directories.tests` – test directory, subject to assigned ownership
@@ -100,17 +102,21 @@ Say what stopped you.
 
 Use the fewest clear words that preserve all necessary information.
 
-## Answer the reader's question
-
-- Lead with the answer, recommendation, or result the reader needs
-- Give enough context for the reader to understand and act
-    - A short reply can be a direct sentence or a few bullets
-    - Add context, a problem statement, or a solution section only when the reader needs it
-- Match detail to the audience
-    - A human needs the facts that change a decision or next action
-    - An agent handoff needs every constraint required to continue correctly
-    - A durable document must make sense to someone outside the original conversation
-- Preserve necessary qualifications, evidence, errors, security warnings, accessibility requirements, and destructive-action confirmations
+## Fit the answer to the audience
+
+- Start with what the reader knows, what they do not know, and what they need from this answer
+    - Lead with the answer, recommendation, or result they need
+    - Include only the context needed to understand it and act; repeat known information only when necessary to connect the new information
+    - Omit a detail only when it does not affect the reader's understanding, decision, or next action
+    - If unsure whether a detail matters, include its essential point briefly rather than relying on the reader to ask
+- When reporting information to the user, be extremely concise and sacrifice grammar for sake of concision
+    - A headline or three-word answer is enough when it fully answers the question
+    - Use fragments freely; skip introductions, recaps, and supporting detail the user does not need
+    - Shorten wording, not meaning; keep conditions and ownership clear
+- Match completeness to the audience, not a length target
+    - An agent handoff needs every detail required to continue correctly, without padding
+    - A durable document needs enough context and precise wording to stand alone for its intended reader; chat's grammar shortcuts do not apply
+- Preserve necessary qualifications, evidence, errors, security warnings, accessibility requirements, and destructive-action confirmations; concision never overrides required disclosures
 - Separate the current answer from decision history
     - State what applies now before explaining how the decision changed
 
@@ -142,7 +148,7 @@ Use the fewest clear words that preserve all necessary information.
 
 ## Write in plain language
 
-- Prefer common, concrete words and natural word order
+- Prefer common, concrete words; use natural word order when it helps understanding
     - Keep necessary technical terms and define unfamiliar abbreviations
     - Cut grand claims, filler, repeated points, and metaphors the reader must decode
     - Use examples when they explain a point faster than an abstract description
@@ -154,20 +160,24 @@ Use the fewest clear words that preserve all necessary information.
     - Prefer active voice, present-tense descriptions, and direct instructions
     - Keep passive voice when the actor is unknown or irrelevant
 - State claims at the strength supported by evidence
-    - Name sources, checks run, results, and remaining uncertainty
+    - Include sources, checks run, results, and uncertainty when the reader needs them to judge the claim or act
+    - Keep verification rigorous even when its supporting detail stays out of the report
     - Explain an important distinction, including what something does not do, when the reader needs it
 - Use sentence-case headings and restrained emphasis
-- Use straight quotes, the Oxford comma, and three periods for an ellipsis
-- Use a period, parentheses, or a spaced en dash instead of an em dash
+- Use straight quotes and three periods for an ellipsis; use the Oxford comma in durable prose
+- Prefer parentheses over spaced en dashes for asides; use a period for a separate thought, never an em dash
+    - Use short parenthetical clarifications or examples (e.g., a concrete input) when they make something complex or ambiguous easier to understand
 - Carry meaning in words, not emoji or color alone
 - Format Markdown so the reader sees the intended grouping
     - Indent nested bullets four spaces per level and leave a blank line before a list
-    - Use parallel grammar and consistent punctuation within a list
+    - Keep list items parallel in meaning; in durable prose, also use parallel grammar and consistent punctuation
     - Short bullet fragments need no final period
 
 ## Before you send
 
-- Can the reader find the answer without reading every detail?
+- Does this give the reader exactly what they need, given what they already know?
+- Can a headline alone answer the question? If so, stop there.
+- Have you removed unnecessary detail without hiding anything that could change the reader's understanding, decision, or next action?
 - Does every level summarize the detail below it?
 - Do siblings answer the same question at the same level?
 - Can the reader follow the same names from overview to detail?

package/pi/agents/test-writer.md

@@ -32,7 +32,9 @@ You write tests from requirements and application programming interface (API) co
 
 ## Project configuration
 
-Read `project.yaml` in the project folder that `~/.claude/acstack/bin/acstack project-data path` prints for project-specific settings:
+Read `project.yaml` when present in the project folder that `~/.claude/acstack/bin/acstack project-data path` prints. Without configuration, discover settings from repository instructions, manifests, existing tests, and CI under Project configuration in `orchestrator/AGENTS.md`; do not require setup or invent commands. Report invalid config and resolution errors rather than bypassing them.
+
+Configured settings:
 
 - `directories.tests` – where to create test files
 - `directories.source` – source code root (for mirroring structure)
@@ -150,17 +152,21 @@ When complete, report:
 
 Use the fewest clear words that preserve all necessary information.
 
-## Answer the reader's question
-
-- Lead with the answer, recommendation, or result the reader needs
-- Give enough context for the reader to understand and act
-    - A short reply can be a direct sentence or a few bullets
-    - Add context, a problem statement, or a solution section only when the reader needs it
-- Match detail to the audience
-    - A human needs the facts that change a decision or next action
-    - An agent handoff needs every constraint required to continue correctly
-    - A durable document must make sense to someone outside the original conversation
-- Preserve necessary qualifications, evidence, errors, security warnings, accessibility requirements, and destructive-action confirmations
+## Fit the answer to the audience
+
+- Start with what the reader knows, what they do not know, and what they need from this answer
+    - Lead with the answer, recommendation, or result they need
+    - Include only the context needed to understand it and act; repeat known information only when necessary to connect the new information
+    - Omit a detail only when it does not affect the reader's understanding, decision, or next action
+    - If unsure whether a detail matters, include its essential point briefly rather than relying on the reader to ask
+- When reporting information to the user, be extremely concise and sacrifice grammar for sake of concision
+    - A headline or three-word answer is enough when it fully answers the question
+    - Use fragments freely; skip introductions, recaps, and supporting detail the user does not need
+    - Shorten wording, not meaning; keep conditions and ownership clear
+- Match completeness to the audience, not a length target
+    - An agent handoff needs every detail required to continue correctly, without padding
+    - A durable document needs enough context and precise wording to stand alone for its intended reader; chat's grammar shortcuts do not apply
+- Preserve necessary qualifications, evidence, errors, security warnings, accessibility requirements, and destructive-action confirmations; concision never overrides required disclosures
 - Separate the current answer from decision history
     - State what applies now before explaining how the decision changed
 
@@ -192,7 +198,7 @@ Use the fewest clear words that preserve all necessary information.
 
 ## Write in plain language
 
-- Prefer common, concrete words and natural word order
+- Prefer common, concrete words; use natural word order when it helps understanding
     - Keep necessary technical terms and define unfamiliar abbreviations
     - Cut grand claims, filler, repeated points, and metaphors the reader must decode
     - Use examples when they explain a point faster than an abstract description
@@ -204,20 +210,24 @@ Use the fewest clear words that preserve all necessary information.
     - Prefer active voice, present-tense descriptions, and direct instructions
     - Keep passive voice when the actor is unknown or irrelevant
 - State claims at the strength supported by evidence
-    - Name sources, checks run, results, and remaining uncertainty
+    - Include sources, checks run, results, and uncertainty when the reader needs them to judge the claim or act
+    - Keep verification rigorous even when its supporting detail stays out of the report
     - Explain an important distinction, including what something does not do, when the reader needs it
 - Use sentence-case headings and restrained emphasis
-- Use straight quotes, the Oxford comma, and three periods for an ellipsis
-- Use a period, parentheses, or a spaced en dash instead of an em dash
+- Use straight quotes and three periods for an ellipsis; use the Oxford comma in durable prose
+- Prefer parentheses over spaced en dashes for asides; use a period for a separate thought, never an em dash
+    - Use short parenthetical clarifications or examples (e.g., a concrete input) when they make something complex or ambiguous easier to understand
 - Carry meaning in words, not emoji or color alone
 - Format Markdown so the reader sees the intended grouping
     - Indent nested bullets four spaces per level and leave a blank line before a list
-    - Use parallel grammar and consistent punctuation within a list
+    - Keep list items parallel in meaning; in durable prose, also use parallel grammar and consistent punctuation
     - Short bullet fragments need no final period
 
 ## Before you send
 
-- Can the reader find the answer without reading every detail?
+- Does this give the reader exactly what they need, given what they already know?
+- Can a headline alone answer the question? If so, stop there.
+- Have you removed unnecessary detail without hiding anything that could change the reader's understanding, decision, or next action?
 - Does every level summarize the detail below it?
 - Do siblings answer the same question at the same level?
 - Can the reader follow the same names from overview to detail?

package/pi/extension.ts

@@ -648,13 +648,9 @@ export default function acstack(pi: ExtensionAPI): void {
 
 	const orchestratorFile = path.join(packageRoot, "orchestrator", "AGENTS.md");
 	const styleFile = path.join(packageRoot, "output-styles", "ac-writing-style.md");
-	const isProject = (cwd: string) => {
-		const folder = projectFolder(undefined, cwd);
-		return folder !== null && fs.existsSync(path.join(folder, "project.yaml"));
-	};
 	let warnedSubagents = false;
 
-	pi.on("session_start", async (event, ctx) => {
+	pi.on("session_start", async (_event, ctx) => {
 		if (!delegated) linkClis(ctx);
 		projectFolders.delete(path.resolve(ctx.cwd));
 		if (projectFolder(ctx, ctx.cwd) === null) return;
@@ -668,10 +664,6 @@ export default function acstack(pi: ExtensionAPI): void {
 				"warning",
 			);
 		}
-
-		if (event.reason === "startup" && !isProject(ctx.cwd)) {
-			report(ctx, "acstack: no project config found. Run /acstack:setup to set up.");
-		}
 	});
 
 	// /acstack map <args> and /acstack:map <args> both run ACStack's own map
@@ -685,9 +677,10 @@ export default function acstack(pi: ExtensionAPI): void {
 		// Every session, like the plugin's skills on Claude Code.
 		if (skillsPrompt) sections["acstack-skills"] = skillsPrompt;
 
-		if (isProject(ctx.cwd)) {
+		const folder = projectFolder(undefined, ctx.cwd);
+		if (folder !== null) {
 			const orchestrator = readText(orchestratorFile);
-			if (orchestrator) sections["acstack-orchestrator"] = `${orchestratorFor(orchestrator, delegated ? "delegated" : "lead")}\n\nThis repository's ACStack project folder: ${projectFolder(undefined, ctx.cwd)}\n`;
+			if (orchestrator) sections["acstack-orchestrator"] = `${orchestratorFor(orchestrator, delegated ? "delegated" : "lead")}\n\nThis repository's ACStack project folder: ${folder}\n`;
 			else report(ctx, `acstack: could not read ${orchestratorFile}`, "warning");
 		}
 

package/skills/commit/SKILL.md

@@ -45,7 +45,7 @@ For each planned commit:
 
 **This step is non-negotiable.** After drafting the commit message but BEFORE creating the commit, spec sync runs automatically.
 
-The project folder is the path `~/.claude/acstack/bin/acstack project-data path` prints. Read `<project folder>/project.yaml` – if `workflow.spec_sync` is `true` (or not explicitly `false`), run spec sync:
+The project folder is the path `~/.claude/acstack/bin/acstack project-data path` prints. Follow Project configuration in `orchestrator/AGENTS.md` for resolution errors and invalid config. If `project.yaml` is absent, commit using repository instructions without creating ACStack records. When present, read it; if `workflow.spec_sync` is `true` (or not explicitly `false`), run spec sync:
 
 1. Read `<project folder>/domain-map.yaml` (if exists)
 2. Map staged files to spec domains
@@ -62,7 +62,7 @@ The project folder is the path `~/.claude/acstack/bin/acstack project-data path`
 
 **Skip spec sync ONLY when:**
 
-- `workflow.spec_sync` is explicitly `false` in project.yaml
+- `project.yaml` is absent, or `workflow.spec_sync` is explicitly `false`
 - No `<project folder>/domain-map.yaml` exists
 - Changed files don't match any domain
 - Changes are docs/config only (no behavioral changes)
@@ -104,4 +104,4 @@ If commit fails due to pre-commit hooks:
 - NEVER use `git add -A` or `git add .` – stage specific files
 - Always create NEW commits after hook failures
 - Prefer specific file staging over broad patterns
-- Spec sync is MANDATORY – do not skip it unless explicitly disabled in project.yaml
+- Spec sync is MANDATORY when configured project records exist, unless disabled or the skip conditions above apply

package/skills/explore/SKILL.md

@@ -91,9 +91,11 @@ You have full context of the ACStack system. Use it naturally, don't force it.
 
 ### Check for context
 
-At the start, quickly check what exists – maps on the configured tracker
-(`ls "$(~/.claude/acstack/bin/acstack project-data path)/maps/"` on the files backend) and living specs
-(`~/.claude/acstack/bin/acstack list --specs --json`).
+When project configuration exists, check existing maps on its configured tracker
+and existing living specs. Without configuration, explore from repository guidance
+and code without requiring setup or creating records. Follow Project configuration
+in `orchestrator/AGENTS.md` for resolution errors and invalid configuration;
+neither is an absent-config fallback.
 
 ### When no map exists
 

package/skills/implement/SKILL.md

@@ -21,10 +21,13 @@ $ARGUMENTS
 
 ### 1. Find the work
 
-Check the configured tracker for maps (`workflow.maps.tracker` in
-`<project folder>/project.yaml`, where the project folder is the path
-`~/.claude/acstack/bin/acstack project-data path` prints; the map skill's `trackers/` docs declare the
-operations – files backend shown below).
+Resolve the project folder with `~/.claude/acstack/bin/acstack project-data path`.
+Preserve reported resolution errors; do not treat them as missing setup.
+When `project.yaml` exists and configures `workflow.maps.tracker`, check that
+tracker for maps (the map skill's `trackers/` docs declare its operations).
+Without configuration, work directly on the request without tracker writes.
+If the request names a map, establish its storage prerequisite first rather
+than silently ignoring it.
 
 **A map exists** (or `$ARGUMENTS` names one):
 
@@ -56,7 +59,10 @@ small unit of work, and nothing has to declare it small.
 
 ### 2. Read project configuration
 
-Read `<project folder>/project.yaml` for build/test/lint commands and directory paths.
+Read `<project folder>/project.yaml` when present. Otherwise discover commands,
+directories, and environment activation from repository instructions, manifests,
+existing tests, and CI, under Project configuration in `orchestrator/AGENTS.md`.
+Do not invent commands or treat invalid configuration as absent.
 
 ### 3. Create feature branch
 

package/skills/implement/design-pass.md

@@ -32,6 +32,8 @@ Load that context before your first edit under `frontend.directory`. Load it onc
 
 **Check the design gate first**
 
+This pass requires project configuration with a `frontend` section. If configuration is absent, skip this optional pass and use discovered repository checks; do not require setup. Follow Project configuration in `orchestrator/AGENTS.md` for invalid configuration and resolution errors rather than silently skipping them.
+
 The design gate is the set of optional checks impeccable adds to acstack's pipeline. `workflow.design_review` in `<project folder>/project.yaml` turns the gate on; the project folder is the path `~/.claude/acstack/bin/acstack project-data path` prints. Ask acstack for the answer:
 
 ```bash

package/skills/map/SKILL.md

@@ -24,7 +24,11 @@ Two backends ship in this skill's directory: `trackers/github.md` for repos
 with GitHub auth, and `trackers/files.md` as the fallback.
 
 ACStack keeps project data in the project folder, the path
-`~/.claude/acstack/bin/acstack project-data path` prints.
+`~/.claude/acstack/bin/acstack project-data path` prints. If `project.yaml` is
+absent, chart in conversation without tracker writes. Before persisting a map,
+ask the user to establish its project settings through `/acstack:setup`;
+do not create configuration implicitly. Invalid configuration or resolution
+errors require repair under Project configuration in `orchestrator/AGENTS.md`.
 `workflow.maps.tracker` in `<project folder>/project.yaml` (`github` or `files`) records
 the project's choice. If the key names a backend, read the matching doc and use
 its operations. If the key is absent, pick at materialisation time – the moment
@@ -34,8 +38,8 @@ Recommend `github` when the repo qualifies, `files` otherwise. Confirm the
 choice with the user. Then write the key, so later sessions need not re-decide.
 ## Which mode
 
-One command runs two modes, and what already exists picks between them. Check
-the configured tracker for existing maps – `ls "$(~/.claude/acstack/bin/acstack project-data path)/maps/"` on the files
+One command runs two modes, and what already exists picks between them. When
+a tracker is configured, check it for existing maps – `ls "$(~/.claude/acstack/bin/acstack project-data path)/maps/"` on the files
 backend, `gh label list --search "map:" --json name` on GitHub.
 
 If `$ARGUMENTS` names a map, or exactly one exists, work its frontier – the

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

@@ -59,14 +59,14 @@ git status --short
 git log --oneline -3  # recent context
 ```
 
-Read `<project folder>/project.yaml` to understand the project's directory layout, commands, and conventions. ACStack keeps it in the project folder, the path `~/.claude/acstack/bin/acstack project-data path` prints.
+Read `<project folder>/project.yaml` when present to understand directories, commands, and conventions. The project folder is the path `~/.claude/acstack/bin/acstack project-data path` prints. Without configuration, discover these from repository instructions, manifests, existing tests, and CI under Project configuration in `orchestrator/AGENTS.md`; do not require setup. Report resolution errors or invalid config rather than treating them as absent.
 
-Categorize changed files into scopes using the project configuration:
+Categorize changed files using configured or discovered directories:
 
-- **source**: files under `directories.source` from project.yaml
-- **frontend**: files under `frontend.directory` from project.yaml (if configured)
+- **source**: files under configured `directories.source`, or discovered source directories
+- **frontend**: files under configured `frontend.directory`, or discovered frontend directories
 - **config**: `*.yaml`, `*.toml`, `*.json`, config files, etc.
-- **tests**: files under `directories.tests` from project.yaml
+- **tests**: files under configured `directories.tests`, or discovered test directories
 - **other**: everything else
 
 Judge changes by effect, including behavior changed through config, assets, or shipped guidance.
@@ -85,7 +85,7 @@ Read `../../output-styles/ac-writing-style.md` relative to this skill directory;
 **Living specs and architecture:**
 
 ```
-Read the living specs relevant to this change:
+Read existing living specs relevant to this change; skip if none exist:
 - Check the <project folder>/specs/ directory listing
 - Read spec.md files for domains touched by the changed files
   (use <project folder>/domain-map.yaml to map files -> domains)

package/skills/quick-fix/SKILL.md

@@ -95,9 +95,11 @@ Apply the shared policy to the minimal fix.
 ## Step 6: Verify
 
 Use focused regression checks while fixing. One verification owner gathers the
-required final checks from `project.yaml` in the project folder, the path `~/.claude/acstack/bin/acstack project-data path` prints, under Build verification in
-`orchestrator/AGENTS.md`, reusing valid evidence rather than rerunning commands
-for every fix or handoff.
+required final checks under Build verification in `orchestrator/AGENTS.md`,
+using `project.yaml` when present or discovered repository tooling when absent.
+Follow its Project configuration policy for resolution errors and invalid config;
+do not require setup for a general fix. Reuse valid evidence rather than rerunning
+commands for every fix or handoff.
 
 Preserve configured frontend gates. Do not claim completion with failed or blocked
 required checks or unverified configured browser behavior.

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 `<project folder>/project.yaml` for `directories.source`, `directories.tests`, and `frontend` config. The project folder is the path `~/.claude/acstack/bin/acstack project-data path` prints.
+Read `<project folder>/project.yaml` when present for `directories.source`, `directories.tests`, and `frontend`. The project folder is the path `~/.claude/acstack/bin/acstack project-data path` prints. Without config, follow repository instructions and existing tests for placement and runner commands; use the examples below only where they fit that project. Follow Project configuration in `orchestrator/AGENTS.md` for invalid config or resolution errors, not a silent fallback.
 
 ```
 Backend code?             → <tests-dir>/<mirror-source-path>/test_<module>.py
@@ -32,7 +32,7 @@ Mirror the source directory structure. Example: `src/auth/sessions.py` → `test
 Colocated with source. Example: `src/hooks/useAuth.ts` → `src/hooks/__tests__/useAuth.test.ts`.
 
 - Components: `.test.tsx`, pure functions: `.test.ts`
-- Run with `frontend.commands.test` from project.yaml
+- Run with configured `frontend.commands.test`, or the discovered repository test command
 
 ## Layer 3: E2E Tests (Browser)
 

package/skills/writing/examples.md

@@ -2,10 +2,20 @@
 
 These examples apply the shared communication standard in `../../output-styles/ac-writing-style.md` without prescribing one shape for every answer.
 
-## A short reply needs only the answer
+## Fit the answer to what the reader needs
 
-- Write: The build passes
-- Avoid: `## Context`, `## Problem`, and `## Solution` sections to report a successful build
+- Asked whether the build passed: `Build passes`
+- Avoid: Listing commands, timings, and passing checks when the result alone answers the question
+- Asked whether the change is ready: `Tests pass; permission to deploy still needed`
+- Avoid: `Tests pass` when that hides a blocker; keep any detail that changes the reader's understanding, decision, or next action
+- If unsure whether a caveat matters, include its essential point briefly
+- Asked five yes/no questions: give five short answers in the same order, not five explanations
+- Asked which backend works offline, after discussing the options: `Files backend`
+- Avoid: Repeating the options and their trade-offs when the reader already knows them
+- Handing work to another agent: include the files, constraints, checked behavior, blockers, and next action needed to continue
+- Avoid: `Use files backend` as a handoff when the receiving agent lacks the decision's context
+
+Reports to the user can use fragments. Durable documents need precise wording and enough context for their intended reader to understand them without the conversation.
 
 ## Preserve the reason when it changes the action
 
@@ -82,5 +92,7 @@ The second makes the reader guess whether the names identify the same thing.
 - Keep a connected explanation in prose when splitting it would hide the causal relationship
 - Indent nested Markdown bullets four spaces and leave a blank line before a list
 - Write `## Before you finish`, not `## Before You Finish.`
-- Write `proposals, designs, and tasks`, with the Oxford comma
+- In durable prose, write `proposals, designs, and tasks`, with the Oxford comma
 - Report `12 tests pass` in words rather than relying on an icon
+- Prefer parentheses for asides: `Use the local backend (no network needed)`
+- Add a short parenthetical example when it clarifies ambiguity: `Reject reserved names (e.g., CON on Windows)`