@blxzer/pactile 0.5.0 → 0.6.0-beta.4

package/dist/templates/common/bundled-skills/pactile-skill-creator/references/general-authoring.md

@@ -1,189 +1,189 @@
-# General Skill Authoring
-
-Method and patterns for writing reusable agent skills. Imperative rules live in `SKILL.md` Hard Constraints; this file explains how to apply them. For Pactile location choice, read `pactile-skill-locations.md`. For description wording and anti-patterns, read `authoring-rules.md`.
-
-## Gather Requirements
-
-Collect these six elements before writing files:
-
-1. **Purpose and scope**: What specific workflow should this skill solve?
-2. **Trigger scenarios**: When should the agent automatically use it?
-3. **Target location**: Project skill, shared skill, bundled template, or personal skill?
-4. **Domain constraints**: Required tools, APIs, reliability constraints.
-5. **Output style**: Report template, checklist, strict schema, etc.
-6. **Existing patterns**: Are there existing skills or conventions to follow?
-
-### Inferring from Context
-
-If previous conversation already surfaced workflows, patterns, or domain knowledge, infer the skill from that context.
-
-Ask the user when requirements are ambiguous and discrete choices are needed.
-
-## Directory Layout
-
-```
-skill-name/
-├── SKILL.md            # required
-├── scripts/            # optional utility scripts
-├── bin/                # optional compiled binaries
-├── references/         # optional detailed docs (preferred over a single reference.md)
-├── examples/           # optional samples
-└── prompts/            # optional long prompts
-```
-
-Keep the entry file short. Put long guidance one level deep under `references/` and link it from `SKILL.md`.
-
-Generic storage scopes (`~/.agents/skills/` vs project `.agents/skills/`) are not enough for Pactile work. Use `pactile-skill-locations.md` to pick the target directory.
-
-## Core Authoring Principles
-
-### 1. Concise is Key
-
-The context window is shared with conversation history, other skills, and requests. Every token competes for space.
-
-Default assumption: the agent is already very smart. Only add context it does not already have.
-
-Challenge each piece of information:
-
-- Does the agent really need this explanation?
-- Can I assume the agent knows this?
-- Does this paragraph justify its token cost?
-
-### 2. Progressive Disclosure
-
-Put essential information in `SKILL.md`; detailed reference material in separate files that the agent reads only when needed.
-
-Keep references one level deep — link directly from `SKILL.md`. Nested reference chains may result in partial reads.
-
-### 3. One File, One Concern
-
-Each skill should address a single workflow. If a skill tries to do too many things, split it.
-
-### 4. Maximize Determinism
-
-Skills run through multiple independent tool calls. Each call is stateless — no shared session or persistent variables between calls.
-
-Eliminate ambiguity at every layer — description, workflow, script parameters, and output format.
-
-- Internalize decisions: if a value can be decided inside a script (output path, temp filename, timestamp), do not expose it as a parameter.
-- Use fixed literal paths in workflows. The agent copies commands verbatim. Never rely on shell variables staying consistent across separate tool calls.
-- Minimize script parameters. Only require what the agent must provide.
-- Scripts return structured JSON to stdout so the agent can parse the result deterministically.
-- Specify an exact tool-call sequence, for example: "Exactly 3 steps: write file → run command → deliver output."
-- Add stop conditions. Prevent open-ended tool loops for expensive operations.
-
-### 5. Set Appropriate Degrees of Freedom
-
-Match specificity to the task's fragility:
-
-| Freedom Level | When to Use | Example |
-|---------------|-------------|---------|
-| **High** (text instructions) | Multiple valid approaches, context-dependent | Code review guidelines |
-| **Medium** (pseudocode / templates) | Preferred pattern with acceptable variation | Report generation |
-| **Low** (specific scripts) | Fragile operations, consistency critical | Database migrations |
-
-## Recommended SKILL.md Sections
-
-1. Goal
-2. Hard Constraints (imperative one-liners; placed before Workflow)
-3. Workflow
-4. Output Template
-5. When NOT to use this skill
-
-## Common Patterns
-
-### Workflow Pattern
-
-Break operations into explicit steps with a clear tool-call sequence:
-
-```markdown
-## Workflow
-
-1. Gather input data
-2. Process: `<exact command the agent should run>`
-3. Parse output, proceed to the next step
-4. Stop when the condition is met
-```
-
-### Template Pattern
-
-Provide output format templates:
-
-````markdown
-## Output Template
-
-```markdown
-# [Title]
-
-## Summary
-[One-paragraph overview]
-
-## Findings
-- Finding 1 with supporting data
-- Finding 2 with supporting data
-```
-````
-
-### Conditional Workflow Pattern
-
-Guide through decision points:
-
-```markdown
-## Workflow
-
-1. Determine the type:
-   **Creating new?** → Follow "Creation workflow" below
-   **Editing existing?** → Follow "Editing workflow" below
-```
-
-### Feedback Loop Pattern
-
-For quality-critical tasks, implement validation:
-
-```markdown
-1. Make edits
-2. Validate: `python scripts/validate.py output/`
-3. If validation fails → fix and re-validate
-4. Only proceed when validation passes
-```
-
-## Utility Scripts
-
-Pre-made scripts are more reliable than generated code, save tokens, and keep behavior consistent.
-
-Script design:
-
-- Only expose parameters the agent must supply (input data, mode selection).
-- Let the script handle internal decisions (output path, temp files, format defaults).
-- Return results as structured JSON to stdout.
-- State whether the agent should **execute** the script or **read** it as reference.
-
-## Minimal Template
-
-```markdown
----
-name: skill-name
-description: Specific capability and trigger scenarios.
----
-
-# Skill Name
-
-## Goal
-One clear objective.
-
-## Hard Constraints
-- Always X. Never Y.
-- Always validate the input before step 2.
-- Never call the API more than 5 times per run.
-
-## Workflow
-1. Step one
-2. Step two
-3. Stop when condition met
-
-## Output Template
-Required output structure.
-
-## When NOT to use this skill
-- Boundary cases.
-```
+# General Skill Authoring
+
+Method and patterns for writing reusable agent skills. Imperative rules live in `SKILL.md` Hard Constraints; this file explains how to apply them. For Pactile location choice, read `pactile-skill-locations.md`. For description wording and anti-patterns, read `authoring-rules.md`.
+
+## Gather Requirements
+
+Collect these six elements before writing files:
+
+1. **Purpose and scope**: What specific workflow should this skill solve?
+2. **Trigger scenarios**: When should the agent automatically use it?
+3. **Target location**: Project skill, shared skill, bundled template, or personal skill?
+4. **Domain constraints**: Required tools, APIs, reliability constraints.
+5. **Output style**: Report template, checklist, strict schema, etc.
+6. **Existing patterns**: Are there existing skills or conventions to follow?
+
+### Inferring from Context
+
+If previous conversation already surfaced workflows, patterns, or domain knowledge, infer the skill from that context.
+
+Ask the user when requirements are ambiguous and discrete choices are needed.
+
+## Directory Layout
+
+```
+skill-name/
+├── SKILL.md            # required
+├── scripts/            # optional utility scripts
+├── bin/                # optional compiled binaries
+├── references/         # optional detailed docs (preferred over a single reference.md)
+├── examples/           # optional samples
+└── prompts/            # optional long prompts
+```
+
+Keep the entry file short. Put long guidance one level deep under `references/` and link it from `SKILL.md`.
+
+Generic storage scopes (`~/.agents/skills/` vs project `.agents/skills/`) are not enough for Pactile work. Use `pactile-skill-locations.md` to pick the target directory.
+
+## Core Authoring Principles
+
+### 1. Concise is Key
+
+The context window is shared with conversation history, other skills, and requests. Every token competes for space.
+
+Default assumption: the agent is already very smart. Only add context it does not already have.
+
+Challenge each piece of information:
+
+- Does the agent really need this explanation?
+- Can I assume the agent knows this?
+- Does this paragraph justify its token cost?
+
+### 2. Progressive Disclosure
+
+Put essential information in `SKILL.md`; detailed reference material in separate files that the agent reads only when needed.
+
+Keep references one level deep — link directly from `SKILL.md`. Nested reference chains may result in partial reads.
+
+### 3. One File, One Concern
+
+Each skill should address a single workflow. If a skill tries to do too many things, split it.
+
+### 4. Maximize Determinism
+
+Skills run through multiple independent tool calls. Each call is stateless — no shared session or persistent variables between calls.
+
+Eliminate ambiguity at every layer — description, workflow, script parameters, and output format.
+
+- Internalize decisions: if a value can be decided inside a script (output path, temp filename, timestamp), do not expose it as a parameter.
+- Use fixed literal paths in workflows. The agent copies commands verbatim. Never rely on shell variables staying consistent across separate tool calls.
+- Minimize script parameters. Only require what the agent must provide.
+- Scripts return structured JSON to stdout so the agent can parse the result deterministically.
+- Specify an exact tool-call sequence, for example: "Exactly 3 steps: write file → run command → deliver output."
+- Add stop conditions. Prevent open-ended tool loops for expensive operations.
+
+### 5. Set Appropriate Degrees of Freedom
+
+Match specificity to the task's fragility:
+
+| Freedom Level | When to Use | Example |
+|---------------|-------------|---------|
+| **High** (text instructions) | Multiple valid approaches, context-dependent | Code review guidelines |
+| **Medium** (pseudocode / templates) | Preferred pattern with acceptable variation | Report generation |
+| **Low** (specific scripts) | Fragile operations, consistency critical | Database migrations |
+
+## Recommended SKILL.md Sections
+
+1. Goal
+2. Hard Constraints (imperative one-liners; placed before Workflow)
+3. Workflow
+4. Output Template
+5. When NOT to use this skill
+
+## Common Patterns
+
+### Workflow Pattern
+
+Break operations into explicit steps with a clear tool-call sequence:
+
+```markdown
+## Workflow
+
+1. Gather input data
+2. Process: `<exact command the agent should run>`
+3. Parse output, proceed to the next step
+4. Stop when the condition is met
+```
+
+### Template Pattern
+
+Provide output format templates:
+
+````markdown
+## Output Template
+
+```markdown
+# [Title]
+
+## Summary
+[One-paragraph overview]
+
+## Findings
+- Finding 1 with supporting data
+- Finding 2 with supporting data
+```
+````
+
+### Conditional Workflow Pattern
+
+Guide through decision points:
+
+```markdown
+## Workflow
+
+1. Determine the type:
+   **Creating new?** → Follow "Creation workflow" below
+   **Editing existing?** → Follow "Editing workflow" below
+```
+
+### Feedback Loop Pattern
+
+For quality-critical tasks, implement validation:
+
+```markdown
+1. Make edits
+2. Validate: `node scripts/validate.mjs output/`
+3. If validation fails → fix and re-validate
+4. Only proceed when validation passes
+```
+
+## Utility Scripts
+
+Pre-made scripts are more reliable than generated code, save tokens, and keep behavior consistent.
+
+Script design:
+
+- Only expose parameters the agent must supply (input data, mode selection).
+- Let the script handle internal decisions (output path, temp files, format defaults).
+- Return results as structured JSON to stdout.
+- State whether the agent should **execute** the script or **read** it as reference.
+
+## Minimal Template
+
+```markdown
+---
+name: skill-name
+description: Specific capability and trigger scenarios.
+---
+
+# Skill Name
+
+## Goal
+One clear objective.
+
+## Hard Constraints
+- Always X. Never Y.
+- Always validate the input before step 2.
+- Never call the API more than 5 times per run.
+
+## Workflow
+1. Step one
+2. Step two
+3. Stop when condition met
+
+## Output Template
+Required output structure.
+
+## When NOT to use this skill
+- Boundary cases.
+```

package/dist/templates/common/bundled-skills/pactile-skill-creator/references/pactile-skill-locations.md

@@ -1,52 +1,11 @@
-# Pactile Skill Locations
-
-Choose the target directory before writing content. Local files are authoritative when they already exist.
-
-## Location Decision Table
-
-| User goal | Default location | Notes |
-| --- | --- | --- |
-| Add a skill for one Pactile project on Cursor | `.cursor/skills/<skill-name>/` | Default target — Pactile is Cursor-only. |
-| Add a skill shared across tools that read the agentskills.io convention | `.agents/skills/<skill-name>/` | Use only when explicitly sharing with a non-Pactile tool that reads the shared agentskills layer. New Pactile behavior stays in `.cursor/skills/`. |
-| Change an existing local Pactile skill | The existing skill directory in the user's project | Preserve local customizations and read the current `SKILL.md` first. |
-| Add a public Pactile bundled skill | `packages/cli/src/templates/common/bundled-skills/<skill-name>/` | Only when working in the Pactile source repository. Update tests that assert bundled skill installation and template tracking. |
-| Add a personal cross-project skill | User's configured global skills directory | Requires explicit user approval because it changes global behavior outside the project. |
-
-## Relationship To `pactile-meta`
-
-Use `pactile-meta` to understand where local Pactile files live and which platform entry point should be changed.
-
-Use `pactile-skill-creator` after the task is clearly about authoring or reviewing the content of a skill:
-
-- frontmatter quality
-- trigger descriptions
-- hard constraints
-- workflow shape
-- references
-- examples
-- deterministic scripts
-- final quality review
-
-Do not copy the full skill-writing guide into `pactile-meta`. `pactile-meta` should route to this skill for detailed authoring guidance.
-
-## Relationship To Cursor `create-skill`
-
-Cursor may provide its own built-in `create-skill` helper. Treat it as a platform-owned helper, not as Pactile source material to edit.
-
-For Pactile work:
-
-- Use `pactile-skill-creator` for Pactile-compatible content and multi-platform boundaries.
-- Keep the skill name `pactile-skill-creator` to avoid colliding with Cursor's built-in skill.
-- If a user explicitly asks for Cursor-only behavior, write to the local `.cursor/skills/` directory and follow the platform's current file format.
-
-## Upstream Bundled Skill Notes
-
-When adding or modifying a bundled skill in the Pactile source repository:
-
-- Do not edit `dist/` directly.
-- Keep the bundled skill public and project-agnostic.
-- Put the skill under `packages/cli/src/templates/common/bundled-skills/`.
-- Include a short `SKILL.md` and lazy-loadable references when the guidance is long.
-- Search for hard-coded bundled skill lists or tests before editing.
-- Update `pactile-meta` only to route users to the new skill where appropriate.
-- Validate template collection, platform installation, and hash tracking with focused tests.
+# Pactile Skill locations
+
+| Need | Location | Ownership |
+| --- | --- | --- |
+| Project-local Codex Skill | `.agents/skills/<name>/SKILL.md` | User-owned unless the ownership ledger explicitly claims it |
+| Project coding rule | `.pactile/spec/` | User-owned |
+| Bundled product Skill | `packages/cli/src/templates/common/bundled-skills/<name>/` in the Pactile source repository | Product-owned |
+
+Inspect the project's existing Skill names and ownership before writing. Do not overwrite a generated Skill silently. A project-local change belongs in the project; an upstream product change belongs in the Pactile repository with validation.
+
+Older host Skill directories can remain after upgrade. They are migration inputs, not new Pactile installation targets.

package/dist/templates/common/bundled-skills/pactile-skill-creator/references/review-checklist.md

@@ -1,52 +1,52 @@
-# Skill Review Checklist
-
-Use this checklist before handing off a new or modified skill.
-
-## Frontmatter
-
-- [ ] `name` uses lowercase letters, numbers, and hyphens only.
-- [ ] `description` is third-person, specific, and includes trigger terms.
-- [ ] `description` includes both what the skill does (WHAT) and when to use it (WHEN).
-- [ ] The skill name does not collide with a platform built-in helper unless that is intentional.
-- [ ] The skill name is specific (`processing-pdfs`), not vague (`helper`, `utils`, `tools`).
-
-## Scope And Boundaries
-
-- [ ] The skill owns one coherent workflow.
-- [ ] `When NOT To Use` or equivalent boundary guidance is present when triggers may overlap.
-- [ ] Project-private rules are in `.pactile/spec/` or a project-local skill, not in a public bundled skill.
-- [ ] The skill distinguishes local project customization from upstream Pactile source changes.
-- [ ] Terminology is consistent throughout.
-
-## Entry File
-
-- [ ] `SKILL.md` is concise and under 500 lines.
-- [ ] `SKILL.md` is written in English unless the target platform or user explicitly requires another language.
-- [ ] `SKILL.md` contains the minimum routing and workflow needed to start.
-- [ ] `## Hard Constraints` appears before `## Workflow` when constraints exist.
-- [ ] Hard constraints are imperative one-liners (`Always X. Never Y.`).
-- [ ] The same rule is not repeated in multiple sections; Hard Constraints is the only rule list.
-- [ ] Workflow has an explicit tool-call sequence and stop conditions.
-- [ ] Tool usage limits are stated when applicable.
-
-## References And Assets
-
-- [ ] Long guidance lives in directly linked reference files.
-- [ ] Every referenced file, script, prompt, or example exists.
-- [ ] Reference paths are relative to the skill directory.
-- [ ] Examples demonstrate a complete workflow boundary, not just a fragment.
-
-## Scripts
-
-- [ ] Scripts are necessary for determinism, not decorative.
-- [ ] Scripts expose only necessary parameters.
-- [ ] Scripts do not rely on shell variables or state from a previous tool call.
-- [ ] Scripts return structured JSON to stdout when they mutate files or provide machine-readable status.
-- [ ] Syntax checks were run for modified scripts when applicable.
-
-## Pactile Template Integration
-
-- [ ] Bundled skills live under `packages/cli/src/templates/common/bundled-skills/`.
-- [ ] Tests or structured checks confirm platform skill installation and template hash tracking where relevant.
-- [ ] `pactile-meta` references route to this skill where useful without duplicating full authoring rules.
-- [ ] `dist/` was not edited as source.
+# Skill Review Checklist
+
+Use this checklist before handing off a new or modified skill.
+
+## Frontmatter
+
+- [ ] `name` uses lowercase letters, numbers, and hyphens only.
+- [ ] `description` is third-person, specific, and includes trigger terms.
+- [ ] `description` includes both what the skill does (WHAT) and when to use it (WHEN).
+- [ ] The skill name does not collide with a platform built-in helper unless that is intentional.
+- [ ] The skill name is specific (`processing-pdfs`), not vague (`helper`, `utils`, `tools`).
+
+## Scope And Boundaries
+
+- [ ] The skill owns one coherent workflow.
+- [ ] `When NOT To Use` or equivalent boundary guidance is present when triggers may overlap.
+- [ ] Project-private rules are in `.pactile/spec/` or a project-local skill, not in a public bundled skill.
+- [ ] The skill distinguishes local project customization from upstream Pactile source changes.
+- [ ] Terminology is consistent throughout.
+
+## Entry File
+
+- [ ] `SKILL.md` is concise and under 500 lines.
+- [ ] `SKILL.md` is written in English unless the target platform or user explicitly requires another language.
+- [ ] `SKILL.md` contains the minimum routing and workflow needed to start.
+- [ ] `## Hard Constraints` appears before `## Workflow` when constraints exist.
+- [ ] Hard constraints are imperative one-liners (`Always X. Never Y.`).
+- [ ] The same rule is not repeated in multiple sections; Hard Constraints is the only rule list.
+- [ ] Workflow has an explicit tool-call sequence and stop conditions.
+- [ ] Tool usage limits are stated when applicable.
+
+## References And Assets
+
+- [ ] Long guidance lives in directly linked reference files.
+- [ ] Every referenced file, script, prompt, or example exists.
+- [ ] Reference paths are relative to the skill directory.
+- [ ] Examples demonstrate a complete workflow boundary, not just a fragment.
+
+## Scripts
+
+- [ ] Scripts are necessary for determinism, not decorative.
+- [ ] Scripts expose only necessary parameters.
+- [ ] Scripts do not rely on shell variables or state from a previous tool call.
+- [ ] Scripts return structured JSON to stdout when they mutate files or provide machine-readable status.
+- [ ] Syntax checks were run for modified scripts when applicable.
+
+## Pactile Template Integration
+
+- [ ] Bundled skills live under `packages/cli/src/templates/common/bundled-skills/`.
+- [ ] Tests or structured checks confirm platform skill installation and template hash tracking where relevant.
+- [ ] `pactile-meta` references route to this skill where useful without duplicating full authoring rules.
+- [ ] `dist/` was not edited as source.

package/dist/templates/common/bundled-skills/pactile-spec-bootstrap/SKILL.md

@@ -1,41 +1,41 @@
----
-name: pactile-spec-bootstrap
-description: "Bootstrap project-specific Pactile coding specs with a platform-neutral single-agent workflow. Use when creating or refreshing .pactile/spec guidelines, analyzing a codebase with GitNexus, ABCoder, or source inspection, decomposing package/layer spec work, and writing real codebase-backed spec docs without placeholder text."
----
-
-# Pactile Spec Bootstrap
-
-Use this skill to create or refresh `.pactile/spec/` guidelines from the real codebase. One capable agent owns the full loop: analyze the repository, choose the spec boundaries, write the docs, and verify the result. The workflow does not depend on a specific host, CLI, or agent brand.
-
-## Workflow
-
-1. Confirm Pactile is initialized and inspect the current `.pactile/spec/` tree.
-2. Analyze the repository architecture with the best available tools: GitNexus, ABCoder, language tooling, and direct source reads.
-3. Decompose the spec work by package and layer only when that reflects the actual codebase.
-4. Fill or reshape the spec files with concrete patterns, file paths, examples, and anti-patterns from the project.
-5. Verify that the final specs are internally consistent and contain no template placeholders.
-
-## Reference Routing
-
-| Need | Read |
-|------|------|
-| Repository architecture analysis | [references/repository-analysis.md](references/repository-analysis.md) |
-| Spec work decomposition and task planning | [references/spec-task-planning.md](references/spec-task-planning.md) |
-| Writing high-signal Pactile spec files | [references/spec-writing.md](references/spec-writing.md) |
-| GitNexus and ABCoder MCP setup | [references/mcp-setup.md](references/mcp-setup.md) |
-
-## Operating Rules
-
-- Treat templates as starting points, not contracts. Delete, rename, split, or add spec files when the repository calls for it.
-- Prefer source-backed rules over generic advice. Every important recommendation should point at a real file or repeated local pattern.
-- Keep execution single-owner by default. Optional helper agents are an implementation detail, not a requirement or user-visible dependency.
-- Do not write platform-specific instructions unless the target project already standardizes on that platform.
-- Do not leave placeholder text, empty headings, or copied boilerplate in `.pactile/spec/`.
-
-## Done Criteria
-
-- `.pactile/spec/` describes the project as it exists now.
-- Each relevant package or layer has practical coding guidance with real examples.
-- Non-applicable template sections are removed.
-- `index.md` files match the final spec file set.
-- Any required setup or analysis assumptions are documented in the relevant spec or task notes.
+---
+name: pactile-spec-bootstrap
+description: "Bootstrap project-specific Pactile coding specs with a platform-neutral single-agent workflow. Use when creating or refreshing .pactile/spec guidelines, analyzing a codebase with whatever code graph or language tooling is already available (or direct source inspection), decomposing package/layer spec work, and writing real codebase-backed spec docs without placeholder text."
+---
+
+# Pactile Spec Bootstrap
+
+Use this skill to create or refresh `.pactile/spec/` guidelines from the real codebase. One capable agent owns the full loop: analyze the repository, choose the spec boundaries, write the docs, and verify the result. The workflow does not depend on a specific host, CLI, or agent brand.
+
+## Workflow
+
+1. Confirm Pactile is initialized and inspect the current `.pactile/spec/` tree.
+2. Analyze the repository architecture with the best available tools: any code graph or language tooling you already run, plus direct source reads.
+3. Decompose the spec work by package and layer only when that reflects the actual codebase.
+4. Fill or reshape the spec files with concrete patterns, file paths, examples, and anti-patterns from the project.
+5. Verify that the final specs are internally consistent and contain no template placeholders.
+
+## Reference Routing
+
+| Need | Read |
+|------|------|
+| Repository architecture analysis | [references/repository-analysis.md](references/repository-analysis.md) |
+| Spec work decomposition and task planning | [references/spec-task-planning.md](references/spec-task-planning.md) |
+| Writing high-signal Pactile spec files | [references/spec-writing.md](references/spec-writing.md) |
+| Code graph and MCP setup (tool-neutral) | [references/mcp-setup.md](references/mcp-setup.md) |
+
+## Operating Rules
+
+- Treat templates as starting points, not contracts. Delete, rename, split, or add spec files when the repository calls for it.
+- Prefer source-backed rules over generic advice. Every important recommendation should point at a real file or repeated local pattern.
+- Keep execution single-owner by default. Optional helper agents are an implementation detail, not a requirement or user-visible dependency.
+- Do not write platform-specific instructions unless the target project already standardizes on that platform.
+- Do not leave placeholder text, empty headings, or copied boilerplate in `.pactile/spec/`.
+
+## Done Criteria
+
+- `.pactile/spec/` describes the project as it exists now.
+- Each relevant package or layer has practical coding guidance with real examples.
+- Non-applicable template sections are removed.
+- `index.md` files match the final spec file set.
+- Any required setup or analysis assumptions are documented in the relevant spec or task notes.