@jakkrichm/create-nexus-devflow 2.0.1 → 2.0.2

package/template/.claude/skills/check-for-updates/SKILL.md

@@ -1,117 +0,0 @@
----name: check-for-updates
-
-description: Install, upgrade, or verify Nexus-DevFlow setup for this machine or project using SETUP-BY-AI.md as the source of truth.
-argument-hint: [optional: target project path, provider/tool, or update intent]
----
-
-# Check For Updates
-
-`Check-For-Updates` is a public companion command for Nexus-DevFlow install, upgrade, and setup verification work.
-
-It is not a numbered mainline stage.
-
-## Mission
-
-Install or upgrade Nexus-DevFlow 2.0 for this machine or target project.
-
-First read `SETUP-BY-AI.md` from the Nexus-DevFlow repository and use it as the operational source of truth.
-
-Detect:
-
-- framework root
-- package version
-- provider or tool
-- target project
-- whether the current setup is using `Codex global`, `Central clone + link`, or `Manual copy / overwrite`
-
-Keep `.workspaces` project-local.
-
-Do not overwrite user instruction files blindly.
-
-After install or upgrade, run `roadmap:validate`, `validate`, and `validate:all` where relevant, then report files changed, installed version, framework root, chosen route, and any manual approval steps.
-
-Repository reference:
-
-```text
-https://github.com/Jakkrich/nexus-devflow
-```
-
-## When To Use
-
-Use this command when:
-
-- the user wants to install Nexus-DevFlow into Codex or another AI tool
-- the user wants to install Nexus-DevFlow into a target project
-- the user wants to upgrade an existing Nexus-DevFlow install
-- the user wants to check whether the current machine or project is on the expected framework version
-- the user needs routing across optional Codex global setup, `Central clone + link`, or `Manual copy / overwrite`
-
-## Operating Rules
-
-- `SETUP-BY-AI.md` is the operational source of truth
-- prefer the safest route that matches the user request and existing environment
-- for project-local setup, prefer `Central clone + link`
-- use `Manual copy / overwrite` only when linking is unsuitable or explicitly rejected
-- treat `AI install` as guided execution of one of the supported routes, not as a separate bundle layout
-- preserve user-authored instructions outside managed Nexus-DevFlow content
-- do not link, copy, or share `.workspaces` from the framework repo into another project
-- if the framework repo is dirty, do not pull automatically; report the dirty files and ask before proceeding with a pull-based update
-- do not claim success until the relevant validation commands pass
-
-## Execution Flow
-
-1. Read `SETUP-BY-AI.md`.
-2. Detect the framework root and confirm the framework files listed there exist.
-3. Detect the installed or target version from `package.json`.
-4. Detect the provider or tool context.
-5. Detect the target project and keep its `.workspaces` local to that project.
-6. Detect the current route already in use, if any:
-   - optional `Codex global`
-   - `Central clone + link`
-   - `Manual copy / overwrite`
-7. Choose the route:
-   - optional `Codex global` only when explicitly requested
-   - `Central clone + link` for project-local setup by default
-   - `Manual copy / overwrite` only when linking is not suitable
-8. If upgrading and the user wants latest, inspect git cleanliness before any pull-based update.
-9. Apply the relevant install or upgrade commands.
-10. Run validation:
-   - `npm.cmd run roadmap:validate`
-   - `npm.cmd run validate`
-   - `npm.cmd run validate:all`
-   - plus provider-specific checks such as `npm.cmd run codex:check-global` when applicable
-11. Report the outcome in the final setup result format.
-
-## Final Report Format
-
-```text
-Nexus-DevFlow setup result
-- Mode:
-- Framework root:
-- Framework version:
-- Target project:
-- Provider:
-- Files changed:
-- Validation:
-- Warnings or manual steps:
-```
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Not a numbered stage
-- Typical entry points: before using DevFlow on a new machine, before linking or copying into a target project, after pulling framework changes, or during provider setup maintenance
-- Typical handoff targets: `Help`, `/00-Discover`, or the user's requested active task after setup is verified
-
-## Sources
-
-- `SETUP-BY-AI.md`
-- `SETUP.md`
-- `AGENTS.md`
-- `package.json`
-- `docs/install-update-troubleshooting.md`
-
-## Next Workflow Recommendation
-
-- Default: return to the user's requested work after setup is verified
-- Common routes: `Help` for routing, `/00-Discover` for new work, or `/50-Verify` when setup validation exposes framework issues

package/template/.claude/skills/devflow-concept-intake/SKILL.md

@@ -1,150 +0,0 @@
----
-name: devflow-concept-intake
-description: Studies external Git repositories, READMEs, prompt frameworks, agent workflows, and engineering-methodology repos before adapting ideas into Nexus-DevFlow. Use when the user asks to research a repo for DevFlow, compare concepts, decide what to adopt or reject, create an adoption proposal, write an option guide for coupled practices, or track upstream sources for adopted concepts.
----
-
-# DevFlow Concept Intake
-
-## Overview
-
-Use this skill to turn external repo ideas into deliberate Nexus-DevFlow decisions. Study the source, critique the principles, discuss trade-offs with the user, then propose adoption only when the concept improves the workflow without unnecessary complexity.
-
-## Core Rule
-
-Do not import ideas just because they are interesting. Every concept must pass through critique, DevFlow fit analysis, and user discussion before it becomes a workflow, agent, skill, artifact, or option guide.
-
-## Core Process
-
-### 1. Source Intake
-
-Identify the source before judging it:
-
-- Record repo URL, README path, docs path, branch, commit, tag, or release when available.
-- Prefer primary source files: `README`, docs, examples, workflow definitions, prompts, CLI scripts, schemas, and changelog.
-- If the user gives only a summary, mark source confidence as `low` and ask for the repo/README before making durable recommendations.
-- Separate stated principles from inferred principles.
-
-For current or remote source facts, browse or fetch the source when tools allow it. Do not rely on memory for live repo state.
-
-### 2. Discussion-First Report
-
-Produce a direct critique before proposing implementation. Use `references/concept-report-template.md` when a written artifact is requested or the analysis is substantial.
-
-Classify each concept:
-
-| Decision | Meaning |
-| :--- | :--- |
-| `Adopt` | Fits DevFlow as-is and adds clear value. |
-| `Adapt` | Useful idea, but must be reshaped for DevFlow. |
-| `Reject` | Does not fit, adds avoidable risk, or conflicts with DevFlow goals. |
-| `Defer` | Potentially useful, but needs evidence, a real use case, or upstream maturity. |
-
-Be explicit about what not to take. A rejected idea is useful output, not a failure.
-
-### 3. Adoption Proposal
-
-Only create an adoption proposal after the user agrees the concept is worth exploring. Use `references/adoption-proposal-template.md`.
-
-Map the concept to the smallest fitting DevFlow surface:
-
-| Target | Use When |
-| :--- | :--- |
-| Workflow | The idea changes phase order, gates, or user-visible commands. |
-| Agent | The idea needs a specialist persona with a bounded responsibility. |
-| Skill | The idea is reusable guidance or a discipline layer inside existing workflows. |
-| Artifact | The idea needs persistent JSON or Markdown state. |
-| Option guide | The idea is useful only as an optional bundle of practices. |
-| Wiki/docs | The idea is knowledge, not behavior. |
-
-Prefer skill-backed or option-guide adoption before adding new slash workflows. Keep the canonical `/00-Discover -> /10-Define -> /20-Spec -> /30-Plan -> /40-Implement -> /50-Verify -> /60-Report -> /70-Release` path stable unless the concept improves a core invariant.
-
-### 4. Coupled Concepts And Option Packs
-
-When principles must be used together, do not scatter them across unrelated flows. Write them as an option pack:
-
-- Name the pack with the `devflow-*` prefix.
-- State which concepts are mandatory together and which are optional.
-- Define when to activate the pack.
-- Define what workflows, agents, skills, artifacts, and validation gates are affected.
-- Include an explicit "Do not use this option when..." section.
-
-Examples:
-
-- `devflow-upstream-sync-pack`: use only when adopting concepts that need regular upstream review.
-- `devflow-agent-discipline-pack`: use when multiple agent behavior rules must work together.
-- `devflow-research-to-adoption-pack`: use when repo study, proposal, and tracking must be chained.
-
-### 5. Upstream Tracking
-
-Track upstream only for concepts the user chooses to adopt or actively evaluate. Use `references/upstream-tracking-template.md`.
-
-Record:
-
-- Source repo and exact revision.
-- Adopted concepts and local DevFlow mapping.
-- Local files or workflows affected.
-- Update strategy: manual review, scheduled review, diff-based review, or no tracking.
-- Compatibility risk if upstream changes.
-- Credit and license notes when applicable.
-
-Do not promise automatic syncing unless the repository has a clear, testable transformation path. Prefer reviewable update notes over blind merges.
-
-## Fit Criteria
-
-Favor concepts that:
-
-- Reduce ambiguity in agent work.
-- Improve traceability, validation, or recovery.
-- Strengthen user-controlled phase gates.
-- Fit the markdown-first stage artifact contract.
-- Can be explained as a small rule, skill, option, or workflow addition.
-- Preserve source credit and make upstream drift visible.
-
-Reject or defer concepts that:
-
-- Add autonomous execution that skips human approval gates.
-- Require copying large frameworks wholesale.
-- Make core workflows harder to understand.
-- Depend on brittle prompt magic with no observable artifact.
-- Duplicate an existing DevFlow skill, agent, or workflow.
-- Create tracking burden without clear recurring value.
-
-## Output Expectations
-
-For lightweight discussion, answer in Thai or the user's language with:
-
-- Source studied.
-- Main principles found.
-- `Adopt / Adapt / Reject / Defer` table.
-- Direct critique.
-- Recommended next DevFlow action.
-
-For substantial work, produce one or more Markdown artifacts under an appropriate workspace path such as:
-
-```text
-devflow/research/devflow-concepts/{source-slug}/concept-report.md
-devflow/research/devflow-concepts/{source-slug}/adoption-proposal.md
-devflow/research/devflow-concepts/{source-slug}/upstream-tracking.md
-```
-
-Ask before writing files unless the user explicitly requested artifacts.
-
-## Red Flags
-
-- Summarizing the repo without giving a recommendation.
-- Treating upstream popularity as proof of DevFlow fit.
-- Proposing a new workflow when a skill or option guide is enough.
-- Omitting the "do not adopt" list.
-- Tracking every studied repo instead of only adopted or actively evaluated concepts.
-- Mixing source truth, interpretation, and local proposal in one undifferentiated document.
-
-## Verification
-
-Before finishing:
-
-- Confirm the source and revision confidence.
-- Confirm every major concept has `Adopt`, `Adapt`, `Reject`, or `Defer`.
-- Confirm rejected concepts and reasons are included.
-- Confirm any adoption proposal maps to a specific DevFlow surface.
-- Confirm coupled concepts are represented as an option pack.
-- Confirm upstream tracking exists only when adoption or active evaluation is chosen.

package/template/.claude/skills/devflow-concept-intake/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "DevFlow Concept Intake"
-  short_description: "Evaluate repo concepts for DevFlow adoption"
-  default_prompt: "Use $devflow-concept-intake to study this repo or README, critique the concepts, and propose whether Nexus-DevFlow should adopt, adapt, reject, or track them."

package/template/.claude/skills/devflow-concept-intake/references/adoption-proposal-template.md

@@ -1,60 +0,0 @@
-# Adoption Proposal Template
-
-Use this template for phase 2 after the user agrees a concept is worth exploring.
-
-```markdown
-# DevFlow Adoption Proposal: {concept-name}
-
-## Recommendation
-
-Adopt | Adapt | Defer
-
-## Why This Belongs In Nexus-DevFlow
-
-Explain the value in terms of DevFlow goals: clearer agent behavior, safer workflow gates, better artifacts, stronger validation, or reusable knowledge.
-
-## Target DevFlow Surface
-
-| Surface | Change |
-| :--- | :--- |
-| Workflow |  |
-| Agent |  |
-| Skill |  |
-| Artifact |  |
-| Option guide |  |
-| Wiki/docs |  |
-
-## Smallest Useful Version
-
-Describe the smallest change that proves the concept works inside DevFlow.
-
-## What Changes
-
-- Files or folders:
-- Commands or workflows:
-- Agent behavior:
-- Artifacts:
-- Validation:
-
-## What Does Not Change
-
-State core DevFlow behavior that must remain stable.
-
-## Option Pack
-
-Use this section only when concepts must be used together.
-
-- Pack name:
-- Required concepts:
-- Optional concepts:
-- Activation trigger:
-- Do not use when:
-
-## Risks And Rejection Criteria
-
-List reasons to stop or roll back.
-
-## Validation Plan
-
-List exact checks, scripts, docs review, or test tasks needed before considering adoption complete.
-```

package/template/.claude/skills/devflow-concept-intake/references/concept-report-template.md

@@ -1,47 +0,0 @@
-# Concept Report Template
-
-Use this template for phase 1: discussion-first repo or README study.
-
-```markdown
-# Concept Report: {source-name}
-
-## Source
-
-- Repo or document:
-- Revision, tag, branch, or date checked:
-- Files read:
-- Source confidence: high | medium | low
-
-## What The Source Is Trying To Do
-
-Summarize the source in plain language. Separate the project's stated goal from your inference.
-
-## Principles Found
-
-| Principle | Evidence | Interpretation |
-| :--- | :--- | :--- |
-|  |  |  |
-
-## Decision Matrix
-
-| Concept | Decision | Why | DevFlow Fit |
-| :--- | :--- | :--- | :--- |
-|  | Adopt |  |  |
-|  | Adapt |  |  |
-|  | Reject |  |  |
-|  | Defer |  |  |
-
-## Direct Critique
-
-State what is strong, what is weak, what is overbuilt, what is missing, and what should not be copied into Nexus-DevFlow.
-
-## Discussion Questions
-
-- 
-- 
-- 
-
-## Recommended Next Step
-
-Choose one: stop, discuss, write adoption proposal, create option pack, or track upstream.
-```

package/template/.claude/skills/devflow-concept-intake/references/upstream-tracking-template.md

@@ -1,51 +0,0 @@
-# Upstream Tracking Template
-
-Use this template for phase 3 only after the user chooses to adopt or actively evaluate a source concept.
-
-```markdown
-# Upstream Tracking: {source-name}
-
-## Source
-
-- Repo:
-- Upstream revision:
-- License:
-- Credit:
-- Date recorded:
-
-## Adopted Or Evaluated Concepts
-
-| Source Concept | Local DevFlow Mapping | Status |
-| :--- | :--- | :--- |
-|  |  | adopted | evaluating | rejected |
-
-## Local Integration Points
-
-- Workflows:
-- Agents:
-- Skills:
-- Artifacts:
-- Docs/wiki:
-- Scripts:
-
-## Update Strategy
-
-Choose one:
-
-- Manual review: revisit only when user asks.
-- Scheduled review: revisit on a calendar or release cadence.
-- Diff-based review: compare upstream changes against recorded revision.
-- No tracking: preserve credit, but do not follow upstream.
-
-## Compatibility Notes
-
-Explain what could break if upstream changes, and what local decisions intentionally diverge from upstream.
-
-## Review Checklist
-
-- [ ] Compare upstream README or docs against recorded revision.
-- [ ] Check whether adopted concepts changed meaning.
-- [ ] Check whether local DevFlow mapping is still valid.
-- [ ] Update adoption proposal or option guide if needed.
-- [ ] Preserve credit and license notes.
-```

package/template/.claude/skills/devflow-wiki/SKILL.md

@@ -1,75 +0,0 @@
----
-name: devflow-wiki
-description: Use when creating, updating, linting, querying, or deciding whether to ingest Nexus-DevFlow framework or project wiki knowledge under devflow/wiki.
----
-
-# DevFlow Wiki
-
-Use DevFlow Wiki to compile reusable knowledge from source artifacts into small, source-backed Markdown pages.
-
-## Core Rules
-
-- Treat wiki pages as compiled knowledge, not source truth.
-- Keep `framework` and `project` namespaces separate.
-- Include `## Sources` on every page.
-- Use `_drafts/` for generated or unreviewed project pages.
-- Prefer one focused page over broad rewrites.
-- Do not ingest noisy logs, unverified hypotheses, or routine edits with no reusable lesson.
-
-## Namespace Decision
-
-| Scope | Use For | Path |
-| :--- | :--- | :--- |
-| `framework` | DevFlow workflows, agents, commands, install behavior, output contracts, token/context rules | `devflow/wiki/framework/` |
-| `project` | Target project architecture, domain concepts, decisions, patterns, gotchas, task lessons | `devflow/wiki/project/` |
-
-Promote project pages to framework only when the lesson applies beyond one project.
-
-## Commands
-
-Initialize and maintain wiki pages through the documented markdown structure under `devflow/wiki/`. Do not rely on the retired PRP runtime for wiki commands.
-
-Use `Wiki {scope} ingest {source}` for workflow-level ingestion and route reporting.
-
-## Project Wiki Contract
-
-Every project wiki uses:
-
-```text
-devflow/wiki/project/
-|-- index.md
-|-- architecture/
-|-- decisions/
-|-- domain/
-|-- gotchas/
-|-- patterns/
-|-- tasks/
-|-- token-context/
-`-- _drafts/
-```
-
-Each published page should follow `.agent/resources/schemas/wiki_page.template.md`.
-
-## Ingest Heuristics
-
-Ingest when the source contains reusable knowledge:
-
-- verified QA evidence
-- confirmed root cause and prevention
-- durable project decision
-- stable architecture or domain concept
-- repeated gotcha or risk pattern
-- context/token optimization lesson
-
-Skip ingest when the source is one-off, unverified, noisy, or already represented in a focused page.
-
-## Output Expectation
-
-Always report:
-
-- pages created or updated
-- source artifacts used
-- lint result or remaining issue
-- next workflow recommendation
-- wiki update recommendation
-

package/template/.claude/skills/english-to-thai-translator/SKILL.md

@@ -1,125 +0,0 @@
----
-name: english-to-thai-translator
-description: English to Thai translation with context awareness for software development documentation and user interfaces.
-allowed-tools: Read, Grep, Glob
----
-
-# 🇹🇭 English to Thai Translation Skill
-
-This skill enables AI agents to translate English text to Thai while maintaining technical accuracy and contextual meaning. It's designed specifically for software development environments where precise terminology is crucial.
-
-## 🎯 When to Use This Skill
-
-- Translating technical documentation from English to Thai
-- Localizing user interface elements (buttons, labels, messages)
-- Converting code comments and developer notes
-- Creating multilingual project specifications
-- Translating API documentation or technical requirements
-
-## 📝 Translation Guidelines
-
-### Technical Terminology
-- Maintain consistency with existing project terminology
-- Use appropriate Thai technical terms for software concepts
-- Preserve acronyms and abbreviations when they're standard in Thai context
-- When no direct Thai equivalent exists, use transliteration + explanation
-
-### Style and Tone
-- Keep formal tone for documentation and specifications
-- Use conversational tone for user-facing interfaces
-- Maintain consistent terminology throughout the document
-- Ensure translations are culturally appropriate for Thai audience
-
-### Special Considerations
-- **Code Comments**: Preserve code structure, translate only comments
-- **API Documentation**: Maintain parameter names and technical descriptions
-- **UI Text**: Follow Thai text direction (left-to-right) and spacing conventions
-- **Numbers and Dates**: Use Thai number formats and date conventions
-
-## 🛠️ Usage Examples
-
-### Example 1: Translating Documentation
-```
-Original English:
-"Configure the database connection parameters in the config file."
-
-Thai Translation:
-"ตั้งค่าพารามิเตอร์การเชื่อมต่อฐานข้อมูลในไฟล์กำหนดค่า"
-```
-
-### Example 2: Translating UI Elements
-```
-Original English:
-"Save Changes"
-
-Thai Translation:
-"บันทึกการเปลี่ยนแปลง"
-```
-
-### Example 3: Translating Technical Specifications
-```
-Original English:
-"The system shall validate user input before processing."
-
-Thai Translation:
-"ระบบจะต้องตรวจสอบข้อมูลที่ผู้ใช้ป้อนก่อนประมวลผล"
-```
-
-## 📚 Best Practices
-
-### DO ✅
-- Use proper Thai punctuation and spacing conventions
-- Maintain technical accuracy over literal translation
-- Ensure consistency with existing Thai terminology in the project
-- Preserve code formatting when translating comments
-
-### DON'T ❌
-- Don't translate technical terms without context consideration
-- Don't ignore cultural appropriateness for Thai audience
-- Don't break existing code structure or syntax
-- Don't create overly literal translations that lose meaning
-
-## 🧪 Quality Checks
-
-Before completing translation tasks, verify:
-1. Technical accuracy of translated terminology
-2. Cultural appropriateness of the translation
-3. Consistency with project's existing Thai documentation
-4. Proper formatting and spacing for UI elements
-5. No broken links or references in translated content
-
-## 🔄 Integration with PRPs Framework
-
-This skill works within the DevFlow 2.0 workflow:
-1. During `/10-Define` or `/20-Spec`, it can help create multilingual specifications
-2. In `/30-Plan`, it helps explain technical requirements in Thai
-3. During `/40-Implement`, it translates comments and documentation when needed
-4. In `/50-Verify` or `/60-Report`, it helps ensure translated content remains clear and correct
-
-## 📁 File Structure
-
-The skill is designed to work with:
-- Documentation files (`.md`, `.txt`)
-- Code comments (`.js`, `.ts`, `.py`, `.java`)
-- Configuration files that contain text to be translated
-- User interface text resources
-
-## ⚠️ Limitations
-
-This skill provides general translation capabilities but may require human review for:
-- Highly specialized technical domains
-- Cultural nuances and idioms
-- Creative content requiring artistic interpretation
-- Legal or regulatory documents requiring official translations
-
-## 📋 Language Constraints
-
-This skill is strictly limited to translating between English and Thai languages only. All output must be exclusively in either English or Thai, with no inclusion of:
-- Chinese (or any other language)
-- Mixed language content
-- Transliterations that include non-Thai characters
-- Any foreign language elements
-
-The translation must maintain pure English-to-Thai conversion without introducing additional languages or mixed scripts.
-
-*Generated by Nexus-DevFlow Specialist*