@jakkrichm/create-nexus-devflow 2.1.0 → 2.2.1

package/template/.claude/skills/complete/SKILL.md

@@ -1,105 +1,160 @@
 ---
 name: complete
-description: "[Devflow] Fast-Track Complete stage in DevFlow (Blueprint Mode) - final safety pass, archive living spec into categorized history, reset stub, git merge, and close run."
-argument-hint: "{running-id or workspace path}"
+description: "[devflow][F] Wrap up a finished feature, fix, or rollback. Runs a final safety pass, archives its spec to devflow/history/features/, devflow/history/fixes/, or devflow/history/rollbacks/, updates the build plan for features and rollbacks, resets devflow/context/current-feature.md to its stub, makes one work-level commit, then squash-merges the branch to main and deletes it. Merges only with explicit approval, then asks separately before pushing main. Use when the user runs /complete, or asks to finish, wrap up, merge, or close out the current feature, fix, or rollback after it is built and reviewed."
 ---
 
-# Fast-Track: Complete (Blueprint Mode)
-
-$ARGUMENTS
-
-Final delivery, safety pass, archive, and run closure stage in Fast-Track. Validates verification status, archives `devflow/context/current-feature.md` to `devflow/history/{features|fixes|rollbacks}/{xxx-slug}.md`, resets the stub, updates changelog, performs conventional commit & git merge, and closes the run **without auto-generating HTML reports**.
-
-## Invocations & Aliases
-
-- `/complete`: Complete current active run
-- `/complete {id}`: Complete specified ID
-- `$complete`: Codex CLI invocation
-
-## Fast-Track Mainline Workflow
-
-```text
-/feature (หรือ /fix) ──▶ /implement ──▶ /check ──▶ /complete
-```
-
-## Behavior & Contract
-
-When invoked:
-
-### 1. Validate Delivery Pre-conditions
-1. Identify active Running ID from `devflow/context/current-stage.md` or `devflow/context/current-feature.md`.
-2. Read `devflow/context/current-feature.md`.
-3. Confirm:
-   - File contains an active spec (not the idle stub `_Nothing in progress._`).
-   - All checklist items in `## 3. Implementation Checklist` are marked `- [x]`.
-   - `## 5. Verification Evidence` contains passing verification results and empirical command outputs.
-
-### 2. Final Safety Pass & Findings Check
-1. Verify working directory hygiene (no accidental leftover test files or debug statements).
-2. Inspect `devflow/context/findings.md`:
-   - No `P0` or `P1` finding is in `open` or `fixed` status (`fixed` requires re-audit).
-   - Only `closed`, `accepted` (user waived), or `invalid` findings are permitted for completion.
-
-### 3. Update Living Spec & Archive to Categorized History
-1. Append `## 6. Release & Handoff` in `current-feature.md` in **Thai (`th`)**:
-   ```markdown
-   ## 6. Release & Handoff
-   - **Release Digest**: สรุปสิ่งที่ส่งมอบในรอบนี้
-   - **Git Branch**: `{branch_name}`
-   - **Merge Status**: Merged into `main` (Commit `{commit_hash}`)
-   - **Archive Date**: {YYYY-MM-DD}
-   ```
-2. Determine Category:
-   - If spec has `Category: Fix` or `Type: Fix` ➔ `fixes`
-   - If spec has `Category: Rollback` or `Type: Rollback` ➔ `rollbacks`
-   - Otherwise ➔ `features`
-3. Archive `devflow/context/current-feature.md` ➔ `devflow/history/{category}/{xxx-slug}.md`.
-4. If `findings.md` contains resolved entries (`closed`, `accepted`, `invalid`), append a `## Resolved Findings` section to the archive file and clean those resolved entries from `findings.md`.
-5. **Reset Living Spec Stub**: Reset `devflow/context/current-feature.md` to:
-   ```markdown
-   # Current Feature
-
-   _Nothing in progress. Run /feature, /fix, or /rollback to start._
-   ```
-
-### 4. Update Master Ledger (`HISTORY.md`) & CHANGELOG.md
-1. Append a new row to `devflow/history/HISTORY.md` under `## 📜 Master Release Log`:
-   ```markdown
-   | {YYYY-MM-DD} | `{ID}` | {Category} | {Title} | `{commit_hash}` | `Released` | [`{xxx-slug}.md`]({category}/{xxx-slug}.md) |
-   ```
-2. **Keep a Changelog & SemVer**:
-   - If `CHANGELOG.md` exists, append a new version block following SemVer principles:
-     - `Major (+1.0.0)`: Breaking architectural changes or API removal
-     - `Minor (0.+1.0)`: New user-facing feature additions (`Added`)
-     - `Patch (0.0.+1)`: Bug fixes (`Fixed`), documentation (`Docs`), or tweaks (`Changed`)
-
-### 5. Policy on HTML Reports (Strict Rule)
-> [!IMPORTANT]
-> **No Auto-Generated HTML**: ห้ามสร้างไฟล์ `report.html` หรือ `60-report.html` แบบอัตโนมัติในขั้นตอนนี้โดยเด็ดขาด!
-> หากผู้ใช้ต้องการดู HTML Dashboard สวยงาม ให้แจ้งผู้ใช้ว่าสามารถเรียกคำสั่งแยกได้: `/report:html`
-
-### 6. Conventional Commits, Git Merge & Branch Cleanup
-1. **Conventional Commits Format**:
-   - Stage relevant files explicitly.
-   - Use imperative mood: `<type>(<scope>): <short imperative summary>` (e.g. `feat(auth): add password reset flow`, `fix(cli): handle missing config gracefully`).
-   - Types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`.
-2. **Squash-Merge**:
-   - Squash-merge feature branch into target base branch (`main` / `master`) with explicit user approval.
-   - Clean up short-lived feature branch.
-
-### 7. Close Active Run
-Update `devflow/context/current-stage.md`:
-- `Active Discovery ID`: `None`
-- `Active Running ID`: `None (Idle)`
-- `Current Stage`: `Idle (Ready for new /feature, /fix, or /00-explore)`
-- `Living Spec`: `None`
-- `Last Completed Run`: `{ID} ({YYYY-MM-DD})`
-- `Last Updated`: `{YYYY-MM-DD}`
-
-### 8. Output Completion Report & PR Template
-Report to the user:
-- Run successfully completed and merged
-- Archived path: `devflow/history/{category}/{xxx-slug}.md`
-- Standalone HTML command tip: `/report:html` (if HTML view is desired)
-- Pull Request summary block (if PR creation is needed)
-- Workspace is now Idle and ready for the next task.
+# complete - log the finished work, make the work commit, and merge
+
+Where this sits in the workflow:
+
+    /feature, /fix, or /rollback  ->  /implement  ->  [complete]  ->  next
+    (the spec)                         (build it)      (commit + merge + log)
+
+`/implement` built the feature, fix, or rollback on its branch, with optional per-step commit
+checkpoints. This skill closes it out: it logs the work, makes the single
+work-level commit, and squash-merges. Run it only when the work is done,
+reviewed, and the documented `Verify` command, or the fallback build and tests,
+passes.
+
+## Before you start
+
+Confirm the work is actually finished: `devflow/context/current-feature.md`
+holds a real spec, its steps are built on a branch, and `Verify`, or the fallback
+build and tests, passes. If any of the
+spec's done-whens are behavioral, `/check` should have proven them against the
+running app first - don't merge on an unverified claim. Uncommitted step work is
+expected (per-step checkpoints are optional); this skill commits it. Don't require
+the steps to be pre-committed.
+
+## Step 0 - final safety pass
+
+Before logging or committing, run a short safety pass and report blockers only:
+
+- active spec exists and the work is not being completed from `main` or `master`
+- changed files are tied to the active spec, with no unrelated dirty work mixed
+  in (a dirty `devflow/context/findings.md` is expected, since `/audit` writes it)
+- the exact `Verify` command from `AGENTS.md` passed in this session, when one is
+  declared; otherwise the build passed, and tests passed when the project has a
+  declared test command and the change touched logic
+- behavioral done-whens have `/check` evidence or equivalent proof, and there is
+  a clear manual try path
+- if workflow files changed, `.agents` and `.claude` stayed in sync where both
+  adapters exist
+- no P0 or P1 finding in `devflow/context/findings.md` is `open` or `fixed`.
+  `fixed` still blocks on purpose: the repair exists but no review has looked at
+  it - run `/audit` to close it. The only waivers are `accepted` (the user's
+  explicit decision in the current chat, reason recorded; never set it for
+  them) or `invalid` (an `/audit` re-examination verdict with recorded
+  evidence, or the user's explicit call). A missing ledger file means no
+  findings.
+
+Do not claim "passed", "verified", or "working" without naming the command,
+route, screenshot, or output that proves it. Stop before Step 1 if required
+evidence is missing.
+
+## Step 1 - log the work
+
+Check whether the spec is a feature, fix, or rollback. A fix is marked
+`Type: Fix` and has no build-plan number. A rollback is marked `Type: Rollback`
+and records the exact target feature, archive, commit, and parent.
+
+- **Feature** - archive `devflow/context/current-feature.md` to `devflow/history/features/NN-name.md`
+  (NN is the build-plan number), and check it off in `devflow/build-plan.md`
+  (and its parent item once all sub-items are checked).
+- **Fix** - archive it to `devflow/history/fixes/name.md`. A fix isn't a build-plan item, so
+  there's nothing to check off.
+- **Rollback** - archive it to
+  `devflow/history/rollbacks/YYYY-MM-DD-NN-name.md`, preserving the original
+  completed feature archive. Create `devflow/history/rollbacks/` first if an
+  older Blueprint installation does not have it yet. Uncheck the exact target item in
+  `devflow/build-plan.md` and its parent when applicable, then append a concise
+  note to the target line with the rollback date and archive path. Keep the
+  feature number stable. If the user later decides the feature is permanently
+  abandoned rather than pending rebuild, that roadmap decision is a separate
+  plan edit.
+
+**Archive resolved findings.** If `devflow/context/findings.md` holds any
+findings, append a `## Findings` section to the archive file just written with
+every `closed`, `accepted`, or `invalid` entry at its final status (`accepted`
+entries keep their recorded reason). Prefix each ID with the archive name for
+global uniqueness: feature 12's `F-03` becomes `12/F-03`; fixes and rollbacks
+use their archive filename as the prefix. An entry carried forward from earlier
+work archives with the item that resolved it; its **Found** line preserves
+where it came from. Then remove the archived entries from the ledger. Unresolved entries (`open` or `fixed` P2/P3, and `unverified`
+leads) stay in the ledger with their IDs so they are never silently dropped.
+When nothing remains, reset the ledger to exactly this stub, and create it the
+same way if the file is missing (an older install):
+
+    # Findings
+
+    > **Generated file.** The findings ledger: review findings raised by `/audit`
+    > against the work in progress, each with a durable ID, severity (P0-P3), and
+    > status. `/implement` marks repaired findings `fixed`, a later `/audit` pass
+    > moves them to `closed`, and `/complete` refuses to merge while any P0 or P1
+    > finding is `open` or `fixed`, then archives resolved findings with the work
+    > and resets this file.
+
+    _No findings recorded. `/audit` appends findings here when it finds them._
+
+Then reset `devflow/context/current-feature.md` to its current stub ("nothing
+in progress"), including `/rollback` alongside `/feature` and `/fix`. Don't
+commit yet; the next step makes one work commit covering the code and these doc
+changes. The archive is the build history.
+
+**Discard consumed prototypes.** If this feature built the look from `prototypes/`
+- its Design reference pointed there and an early step ported `prototypes/theme.css`
+into the app - delete the `prototypes/` folder now. The tokens live in the real
+stylesheet and the HTML mockups were always throwaway; fold the deletion into this
+feature's commit. Skip this if the feature didn't consume prototypes.
+
+## Step 2 - make the work commit
+
+Stage everything on the branch (any uncommitted step work plus the Step 1 logging
+changes) and make one conventional work commit (for example `feat: <feature>`,
+`fix: <name>`, or `revert: roll back <feature>`). `Verify`, or the fallback build
+and tests, must pass first.
+
+## Step 3 - merge
+
+1. Squash-merge the branch into main, only with the user's explicit go-ahead, so
+   the feature lands as one clean commit regardless of how many checkpoints the
+   branch carried.
+2. Delete the branch after a clean merge.
+3. Stop and ask whether to push local `main` to its upstream. The merge approval
+   does not count as push approval.
+4. Push main only after a separate explicit yes to push main in the current chat.
+   If the repo has no remote or upstream, say so instead of guessing.
+
+Then point the user at `/feature`, `/fix`, or `/rollback` for the next thing.
+
+Finish with a concise **How to try it** note for the completed work. For a
+rollback, explain how to confirm the removed behavior is gone and name one
+unaffected regression path. If the
+manual path is more than a couple of steps, tell the user to run `/try latest`;
+that command can read the archived feature after `current-feature.md` is reset.
+
+## Rules
+
+- The work item is the unit of history: one squashed feature, fix, or rollback
+  commit on main, even if the branch carried several checkpoint commits.
+- A rollback preserves the original feature archive and adds a separate rollback
+  archive. Never rewrite history to make the feature look as if it never existed.
+- Don't merge unfinished or failing work. The documented `Verify` command, or
+  the fallback build and tests, must pass first.
+- Never merge while a P0 or P1 finding is `open` or `fixed` in the ledger. The
+  recorded ways past the gate without code are `accepted` (only by the user's
+  explicit decision, with their reason) or `invalid` (only from re-examination
+  evidence or the user's explicit call); both travel into the archive, never a
+  silent drop.
+- Merging and pushing are the user's calls: get an explicit yes for the merge,
+  then ask whether to push main. Do not treat merge approval, `/complete`, or
+  "looks good" as permission to push.
+- Push main only after a separate explicit yes to push main in the current chat.
+- One item per completion. If a parent feature still has unchecked sub-features,
+  leave the parent unchecked.
+
+## Formatting
+
+Format the output to match the project's conventions in
+`devflow/context/ai-interaction.md`: concise, scannable markdown, with lists for
+enumerations and tables for matrices rather than dense paragraphs.

package/template/.claude/skills/convert-any-to-md/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: convert-any-to-md
-description: '[Devflow] Converts any document (.xlsx, .pdf, .docx, .txt, .csv, .log, .json, .yaml, etc.) or mixed folders into clean Markdown in devflow/reference. Use whenever documents need to be analyzed, summarized, searched, or extracted from.'
+description: "[devflow][B] Converts any document (.xlsx, .pdf, .docx, .txt, .csv, .log, .json, .yaml, etc.) or mixed folders into clean Markdown in devflow/reference. Use whenever documents need to be analyzed, summarized, searched, or extracted from."
 ---
 
 # Convert Any Document to Markdown
@@ -77,4 +77,4 @@ python .agents/skills/convert-any-to-md/scripts/convert_any_to_md.py "C:\path\to
 | `.txt`, `.csv`, `.json`, `.yaml`, `.log` | Plaintext Formatter | N/A | `<name>/<name>.md` |
 
 > [!NOTE]
-> Legacy binary formats (`.xls`, `.doc`) are not supported directly. Ask the user to re-save them as `.xlsx` / `.docx` first.
+> Legacy binary formats (`.xls`, `.doc`) are not supported directly. Ask the user to re-save them as `.xlsx` / `.docx` first.

package/template/.claude/skills/convert-any-to-md/references/setup.md

@@ -0,0 +1,29 @@
+# Environment Setup for convert-any-to-md
+
+Follow these steps to set up the Python dependencies for document conversion.
+
+## 1. Prerequisites
+
+- Python 3.10+
+- pip
+
+## 2. Installation
+
+Run:
+
+```powershell
+python -m pip install -r .agents/skills/convert-any-to-md/scripts/requirements.txt
+```
+
+This installs:
+- `markitdown[xlsx]`
+- `pymupdf` (for PDF image extraction)
+- `openpyxl` (for Excel parsing)
+
+## 3. Verification
+
+```powershell
+python -c "from markitdown import MarkItDown; import fitz; import openpyxl; print('Dependencies OK')"
+```
+
+Expect `Dependencies OK` to print cleanly.