@baoanaz/cviauto 0.6.5

package/dist/templates/codex/skills/finish-work/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: finish-work
+description: "Wrap up an active Cviauto task: archive it (and any other completed-but-unarchived tasks the user wants to clean up) and record a local session journal. Refuses to run if the working tree has uncommitted code changes (those belong in workflow Phase 3.4 first). Use when the user asks to finish / wrap up / call it a day, or invokes $finish-work. If the user explicitly asks to promote a lesson into spec, propose and confirm that spec update before archiving."
+---
+
+# Finish Work
+
+Wrap up the current session: archive the active task (and any other completed-but-unarchived tasks the user wants to clean up) and record the session journal as local Cviauto records. Code commits are NOT done here — those happen in workflow Phase 3.4 before you invoke this skill.
+
+If the user explicitly asks to promote current-session knowledge into spec (for example, "finish-work and write the rule about X into spec"), complete the optional spec-promotion flow before archiving:
+
+1. Load `cviauto-update-spec`.
+2. Propose the target `.cviauto/spec/` file and exact reusable rule.
+3. Write the spec update only after user confirmation.
+4. Then continue with the normal archive + journal steps below.
+
+## Step 1: Survey current state
+
+```bash
+python3 ./.cviauto/scripts/get_context.py --mode record
+```
+
+This prints:
+
+- **My active tasks** — review whether any besides the current one are actually done (code merged, AC met) and should be archived this round.
+- **Git status** — quick visual on what's dirty.
+- **Recent commits** — you'll need their hashes in Step 4 for `--commit`.
+
+If `--mode record` surfaces other completed tasks not tied to the current session, surface them to the user with a one-shot confirmation: "These N tasks look done — archive them too in this round? [y/N]". Default is no; the current active task is always archived in Step 3 regardless.
+
+## Step 2: Sanity check — classify dirty paths
+
+Run:
+
+```bash
+git status --porcelain
+```
+
+Filter out paths under `.cviauto/workspace/` and `.cviauto/tasks/` — those are local Cviauto task/session records and should not block finish-work unless they contain changes the user explicitly wants to publish.
+
+For each remaining dirty path, decide whether it belongs to **the current task** or to **other parallel work** (e.g., another terminal window editing the same repo). Heuristics:
+
+- Paths referenced in the current task's `prd.md` / `implement.jsonl` / `check.jsonl` → current task
+- Paths in code areas matching the task's stated scope, or that you remember editing this session → current task
+- Paths in unrelated areas you have no recollection of touching this session → other parallel work
+
+Then route:
+
+- **Any remaining path looks like current-task work** — bail out with:
+  > "Working tree has uncommitted code changes from this task: `<list>`. Return to workflow Phase 3.4 to commit them before running `$finish-work`."
+
+  Do NOT run `git commit` here. Do NOT prompt the user to commit. The user goes back to Phase 3.4 and the AI drives the batched commit there.
+- **All remaining paths look unrelated** (other parallel-window work) — report them once and continue to Step 3:
+  > "FYI, dirty files outside this task's scope — leaving them for the other window: `<list>`."
+- **Genuinely unsure** — ask the user once: "Are `<list>` this task's work I forgot to commit, or another window's? (commit / ignore)" — then route per their answer.
+
+## Step 3: Archive task(s)
+
+```bash
+python3 ./.cviauto/scripts/task.py archive <task-name> --no-commit
+```
+
+At minimum: the current active task (if any). Plus any extra tasks the user confirmed in Step 1. Archives are local Cviauto records by default; do not create a `chore(task): archive ...` commit unless the user explicitly asks to publish Cviauto bookkeeping.
+
+If there is no active task and the user did not confirm any cleanup archives, skip this step.
+
+## Step 4: Record session journal
+
+```bash
+python3 ./.cviauto/scripts/add_session.py \
+  --title "Session Title" \
+  --commit "hash1,hash2" \
+  --summary "Brief summary" \
+  --no-commit
+```
+
+Use the work-commit hashes produced in Phase 3.4 (visible in Step 1's `Recent commits` list, or via `git log --oneline`) for `--commit`. This records the session locally and does not create a `chore: record journal` commit.
+
+Final git history by default: work commits only. Archive and journal files stay local unless the user explicitly asks to publish Cviauto bookkeeping.
+
+---
+
+## Relationship to Other Skills
+
+```
+Development Flow:
+  Phase 3.4 (workflow.md) -> AI drafts batched commits -> user confirms -> git commit
+                                                                              |
+                                                                              v
+                                                                    $finish-work
+                                                                    (survey + local archive + journal)
+
+Debug Flow:
+  Hit bug -> Fix -> $break-loop -> Knowledge capture
+```
+
+- `$finish-work` — this skill, survey + local archive + record session
+- `$break-loop` — deep analysis after debugging

package/dist/templates/codex/skills/improve-ut/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: improve-ut
+description: "Analyzes changed files and improves unit test coverage using project-specific testing conventions from .cviauto/spec/ unit-test specs. Determines test scope (unit vs integration vs regression), adds or updates tests following existing patterns, and runs validation. Use when code changes need test coverage, after implementing a feature, after fixing a bug, or when test gaps are identified."
+---
+
+# Improve Unit Tests (UT)
+
+Use this skill to improve test coverage after code changes.
+
+## Usage
+
+```text
+$improve-ut
+```
+
+## Source of Truth
+
+Discover and read unit-test specs dynamically:
+
+```bash
+# Discover available packages and their spec layers
+python3 ./.cviauto/scripts/get_context.py --mode packages
+```
+
+Look for packages with `unit-test` spec layer in the output. For each discovered `unit-test/` directory, read all relevant spec files inside it (for example `index.md`, `conventions.md`, `integration-patterns.md`, `mock-strategies.md`).
+
+> If this skill conflicts with the unit-test specs, the specs win.
+
+---
+
+## Execution Flow
+
+1. Inspect changed files:
+   - `git diff --name-only`
+2. Decide test scope using unit-test specs:
+   - unit vs integration vs regression
+   - mock vs real filesystem flow
+3. Add/update tests using existing project test patterns
+4. Run validation:
+
+```bash
+pnpm lint
+pnpm typecheck
+pnpm test
+```
+
+5. Summarize decisions, updates, and remaining test gaps.
+
+---
+
+## Output Format
+
+```markdown
+## UT Coverage Plan
+- Changed areas: ...
+- Test scope (unit/integration/regression): ...
+
+## Test Updates
+- Added: ...
+- Updated: ...
+
+## Validation
+- pnpm lint: pass/fail
+- pnpm typecheck: pass/fail
+- pnpm test: pass/fail
+
+## Gaps / Follow-ups
+- <none or explicit rationale>
+```

package/dist/templates/codex/skills/integrate-skill/SKILL.md

@@ -0,0 +1,221 @@
+---
+name: integrate-skill
+description: "Adapts an external skill into project-specific development guidelines in .cviauto/spec/. Creates guideline sections, code example templates with .template suffix, and updates spec indexes. Use when integrating an external skill, adding a new skill's patterns to project conventions, or incorporating third-party skill best practices into .cviauto/spec/ documentation."
+---
+
+# Integrate Skill into Project Guidelines
+
+Adapt and integrate a reusable skill into your project's development guidelines (not directly into project code).
+
+## Usage
+
+```
+$integrate-skill <skill-name>
+```
+
+**Examples**:
+```
+$integrate-skill frontend-design
+$integrate-skill mcp-builder
+```
+
+## Core Principle
+
+> [!] **Important**: The goal of skill integration is to update **development guidelines**, not to generate project code directly.
+>
+> - Guidelines content -> Write to `.cviauto/spec/{target}/doc.md`
+> - Code examples -> Place in `.cviauto/spec/{target}/examples/skills/<skill-name>/`
+> - Example files -> Use `.template` suffix (e.g., `component.tsx.template`) to avoid IDE errors
+>
+> Where `{target}` is `frontend` or `backend`, determined by skill type.
+
+## Execution Steps
+
+### 1. Read Skill Content
+
+Locate and read the skill instructions:
+- `.agents/skills/<skill-name>/SKILL.md` in the repository
+- Skill list in `AGENTS.md` (when available in current context)
+
+If the skill cannot be found, ask the user for the source path or repository.
+
+### 2. Determine Integration Target
+
+Based on skill type, determine which guidelines to update:
+
+| Skill Category | Integration Target |
+|----------------|-------------------|
+| UI/Frontend (`frontend-design`, `web-artifacts-builder`) | `.cviauto/spec/frontend/` |
+| Backend/API (`mcp-builder`) | `.cviauto/spec/backend/` |
+| Documentation (`doc-coauthoring`, `docx`, `pdf`) | `.cviauto/` or create dedicated guidelines |
+| Testing (`webapp-testing`) | `.cviauto/spec/frontend/` (E2E) |
+
+### 3. Analyze Skill Content
+
+Extract from the skill:
+- **Core concepts**: How the skill works and key concepts
+- **Best practices**: Recommended approaches
+- **Code patterns**: Reusable code templates
+- **Caveats**: Common issues and solutions
+
+### 4. Execute Integration
+
+#### 4.1 Update Guidelines Document
+
+Add a new section to the corresponding `doc.md`:
+
+```markdown
+@@@section:skill-<skill-name>
+## # <Skill Name> Integration Guide
+
+### Overview
+[Core functionality and use cases of the skill]
+
+### Project Adaptation
+[How to use this skill in the current project]
+
+### Usage Steps
+1. [Step 1]
+2. [Step 2]
+
+### Caveats
+- [Project-specific constraints]
+- [Differences from default behavior]
+
+### Reference Examples
+See `examples/skills/<skill-name>/`
+
+@@@/section:skill-<skill-name>
+```
+
+#### 4.2 Create Examples Directory (if code examples exist)
+
+```bash
+# Directory structure ({target} = frontend or backend)
+.cviauto/spec/{target}/
+|-- doc.md                      # Add skill-related section
+|-- index.md                    # Update index
++-- examples/
+    +-- skills/
+        +-- <skill-name>/
+            |-- README.md               # Example documentation
+            |-- example-1.ts.template   # Code example (use .template suffix)
+            +-- example-2.tsx.template
+```
+
+**File naming conventions**:
+- Code files: `<name>.<ext>.template` (e.g., `component.tsx.template`)
+- Config files: `<name>.config.template` (e.g., `tailwind.config.template`)
+- Documentation: `README.md` (normal suffix)
+
+#### 4.3 Update Index File
+
+Add to the Quick Navigation table in `index.md`:
+
+```markdown
+| <Skill-related task> | <Section name> | `skill-<skill-name>` |
+```
+
+### 5. Generate Integration Report
+
+---
+
+## Skill Integration Report: `<skill-name>`
+
+### # Overview
+- **Skill description**: [Functionality description]
+- **Integration target**: `.cviauto/spec/{target}/`
+
+### # Tech Stack Compatibility
+
+| Skill Requirement | Project Status | Compatibility |
+|-------------------|----------------|---------------|
+| [Tech 1] | [Project tech] | [OK]/[!]/[X] |
+
+### # Integration Locations
+
+| Type | Path |
+|------|------|
+| Guidelines doc | `.cviauto/spec/{target}/doc.md` (section: `skill-<name>`) |
+| Code examples | `.cviauto/spec/{target}/examples/skills/<name>/` |
+| Index update | `.cviauto/spec/{target}/index.md` |
+
+> `{target}` = `frontend` or `backend`
+
+### # Dependencies (if needed)
+
+```bash
+# Install required dependencies (adjust for your package manager)
+npm install <package>
+# or
+pnpm add <package>
+# or
+yarn add <package>
+```
+
+### [OK] Completed Changes
+
+- [ ] Added `@@@section:skill-<name>` section to `doc.md`
+- [ ] Added index entry to `index.md`
+- [ ] Created example files in `examples/skills/<name>/`
+- [ ] Example files use `.template` suffix
+
+### # Related Guidelines
+
+- [Existing related section IDs]
+
+---
+
+## 6. Optional: Create Usage Skill
+
+If this skill is frequently used, create a shortcut skill:
+
+```bash
+$create-command use-<skill-name> Use <skill-name> skill following project guidelines
+```
+
+## Common Skill Integration Reference
+
+| Skill | Integration Target | Examples Directory |
+|-------|-------------------|-------------------|
+| `frontend-design` | `frontend` | `examples/skills/frontend-design/` |
+| `mcp-builder` | `backend` | `examples/skills/mcp-builder/` |
+| `webapp-testing` | `frontend` | `examples/skills/webapp-testing/` |
+| `doc-coauthoring` | `.cviauto/` | N/A (documentation workflow only) |
+
+## Example: Integrating `mcp-builder` Skill
+
+### Directory Structure
+
+```
+.cviauto/spec/backend/
+|-- doc.md                           # Add MCP section
+|-- index.md                         # Add index entry
++-- examples/
+    +-- skills/
+        +-- mcp-builder/
+            |-- README.md
+            |-- server.ts.template
+            |-- tools.ts.template
+            +-- types.ts.template
+```
+
+### New Section in doc.md
+
+```markdown
+@@@section:skill-mcp-builder
+## # MCP Server Development Guide
+
+### Overview
+Create LLM-callable tool services using MCP (Model Context Protocol).
+
+### Project Adaptation
+- Place services in a dedicated directory
+- Follow existing TypeScript and type definition conventions
+- Use project's logging system
+
+### Reference Examples
+See `examples/skills/mcp-builder/`
+
+@@@/section:skill-mcp-builder
+```