@jakkrichm/create-nexus-devflow 2.17.2 → 2.17.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/template/.agents/skills/bughunter/SKILL.md +1 -1
- package/template/.agents/skills/devflow/SKILL.md +3 -2
- package/template/.agents/skills/fix/SKILL.md +3 -3
- package/template/.agents/skills/implement/SKILL.md +36 -118
- package/template/.claude/skills/bughunter/SKILL.md +1 -1
- package/template/.claude/skills/devflow/SKILL.md +3 -2
- package/template/.claude/skills/fix/SKILL.md +3 -3
- package/template/.claude/skills/implement/SKILL.md +36 -118
- package/template/AGENTS.md +16 -38
- package/template/devflow/build-plan.md +24 -274
- package/template/devflow/context/ai-interaction.md +15 -14
- package/template/devflow/context/coding-standards.md +5 -4
- package/template/devflow/context/glossary.md +6 -6
- package/template/devflow/project-plan.md +38 -65
- package/template/devflow/reference/help-playbook-protocol.md +33 -0
- package/template/devflow/runs/.gitkeep +1 -0
|
@@ -1,79 +1,52 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Project Plan
|
|
2
2
|
|
|
3
|
-
> **Document Type**: Project Plan (User-Owned)
|
|
4
|
-
> **Purpose**: แหล่งความจริงหลัก (Single Source of Truth) สำหรับวิสัยทัศน์ผลิตภัณฑ์ สถาปัตยกรรมระบบ
|
|
3
|
+
> **Document Type**: Project Plan (User-Owned)
|
|
4
|
+
> **Purpose**: แหล่งความจริงหลัก (Single Source of Truth) สำหรับวิสัยทัศน์ผลิตภัณฑ์ สถาปัตยกรรมระบบ ขอบเขตการทำงาน และข้อกำหนดทางเทคนิค
|
|
5
|
+
> **Workflow**: กรอกข้อมูลให้ครบถ้วนแล้วรัน `/overview` เพื่อประมวลผลเป็น `project-overview.md`
|
|
5
6
|
|
|
6
7
|
---
|
|
7
8
|
|
|
8
|
-
## 1.
|
|
9
|
+
## 1. Problem - What problem are we solving?
|
|
9
10
|
|
|
10
|
-
- **
|
|
11
|
-
- **
|
|
12
|
-
- นักพัฒนาเดี่ยว (Solo Developers) ที่ต้องการความเร็วสูงแต่ยังคงมีระเบียบวินัยและหลักฐานการทดสอบที่ชัดเจน
|
|
13
|
-
- ทีมพัฒนาและองค์กร (Engineering Teams & Tech Leads) ที่ต้องการมาตรฐานการส่งมอบโค้ดที่ตรวจสอบได้ (Traceable), ตรวจสอบย้อนหลังได้ (Auditable) และไม่มีปัญหาโค้ดตีกัน (Zero Merge Conflict)
|
|
14
|
-
- **Core Value Proposition**:
|
|
15
|
-
- **The 3-Pillars Model**: จัดระเบียบบริบทเป็น 3 เสาหลักอย่างชัดเจน — *🔮 Future (Inbox `ideas.md`)* ➔ *⚡ Present (Living Context `devflow/context/`)* ➔ *📦 Past (Categorized History `devflow/history/`)*
|
|
16
|
-
- **Single Living Spec Delivery Model**: งานทุกขนาดใช้วงจรเดียว `/feature` (หรือ `/fix`) ➔ `/implement` ➔ `/check` ➔ `/complete` โดยเพิ่มความลึกของสเปกและหลักฐานตามความซับซ้อนของงาน
|
|
17
|
-
- **Hard Quality Gates**: ระบบปฏิเสธการปล่อยงานเมื่อไม่ผ่านเกณฑ์การทดสอบ หรือมีข้อบกพร่องความปลอดภัยค้างอยู่
|
|
11
|
+
- **Core Problem**: [ระบุปัญหาหลักที่ผู้ใช้กำลังเผชิญ]
|
|
12
|
+
- **Main Purpose**: [ระบุเป้าหมายหลักของระบบ]
|
|
18
13
|
|
|
19
14
|
---
|
|
20
15
|
|
|
21
|
-
## 2.
|
|
22
|
-
|
|
23
|
-
- **
|
|
24
|
-
- **
|
|
25
|
-
|
|
26
|
-
-
|
|
27
|
-
-
|
|
28
|
-
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
16
|
+
## 2. Users - Who is this for?
|
|
17
|
+
|
|
18
|
+
- **Primary Audience**: [เช่น Solo Developers, Content Creators]
|
|
19
|
+
- **Secondary Audience (Later)**: [เช่น ทีมงานองค์กร, ลูกค้าปลายทาง]
|
|
20
|
+
- **User Personas & Access Tiers**:
|
|
21
|
+
- `Anonymous / Guest`: [สิทธิ์การใช้งานทั่วไป]
|
|
22
|
+
- `Authenticated User`: [สิทธิ์การใช้งานหลัก]
|
|
23
|
+
- `Admin`: [สิทธิ์การจัดการระบบ]
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## 3. Features - What does v1 need?
|
|
28
|
+
|
|
29
|
+
### Core MVP Features (v1):
|
|
30
|
+
- **Feature 1**: [คำอธิบายฟีเจอร์]
|
|
31
|
+
- **Feature 2**: [คำอธิบายฟีเจอร์]
|
|
32
|
+
- **Feature 3**: [คำอธิบายฟีเจอร์]
|
|
33
|
+
|
|
34
|
+
### Later / Post-MVP (Not in v1):
|
|
35
|
+
- [เช่น ระบบสมัครสมาชิกและ Billing]
|
|
36
|
+
- [เช่น การส่งออกข้อมูลปริมาณมาก]
|
|
38
37
|
|
|
39
38
|
---
|
|
40
39
|
|
|
41
|
-
##
|
|
42
|
-
|
|
43
|
-
- **
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
3. *Branch-Scoped Context Isolation*: แยกโฟลเดอร์ State ตาม Git Branch ใน `.nexus/branches/<name>/` ป้องกัน Merge Conflict เมื่อทำงานเป็นทีม
|
|
47
|
-
4. *Dynamic Context Slicing*: ส่งเฉพาะบริบทที่จำเป็นต่อ Stage นั้นๆ เข้าสู่ AI ลด Token Bloat 60–70%
|
|
48
|
-
5. *State Drift Reconciler*: ตรวจจับความไม่สอดคล้องระหว่าง Git Diffs กับ Spec Tasks และเสนอทางเลือก Auto-Sync ทันที
|
|
49
|
-
- **Non-Goals**:
|
|
50
|
-
- ไม่ใช่ Proprietary IDE หรือ Closed Cloud SaaS — DevFlow เป็น Transparent Git-Native Layer ที่ฝังตัวในโปรเจกต์ใดก็ได้
|
|
51
|
-
- ไม่ใช่ Auto-GPT ที่ปล่อยให้ AI เขียนโค้ดตามใจโดยไม่มี Human-in-the-Loop Review Gates
|
|
52
|
-
- **Delivery Rules**:
|
|
53
|
-
- เคร่งครัดใน TDD Mandate: โค้ดที่เพิ่มหรือแก้ไขต้องมี Automated Unit Tests เสมอ
|
|
54
|
-
- ห้ามข้ามขั้นตอน Verification: ต้องมีหลักฐานเชิงประจักษ์ (Empirical Proof) ใน `/check` ก่อนอนุมัติ `/complete`
|
|
40
|
+
## 4. Data - What are we storing?
|
|
41
|
+
|
|
42
|
+
- **Core Entities**:
|
|
43
|
+
- [Entity 1]: [Attributes & Purpose]
|
|
44
|
+
- [Entity 2]: [Attributes & Purpose]
|
|
55
45
|
|
|
56
46
|
---
|
|
57
47
|
|
|
58
|
-
##
|
|
59
|
-
|
|
60
|
-
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
- **⚡ Milestone 2: DevFlow MCP Server Hub & Type-Safe Schemas (`IDEA-004`)**
|
|
64
|
-
- พัฒนา MCP Server ผ่าน JSON-RPC สำหรับ Antigravity, Claude, Codex, Cursor
|
|
65
|
-
- ใช้ Zod Schema ควบคุมการอัปเดต Task, Findings, และ Stage State 100% Type-safe
|
|
66
|
-
- **🌿 Milestone 3: Branch-Scoped Context Isolation & Dynamic Router**
|
|
67
|
-
- รองรับการเก็บ State แยกตาม Git Branch ป้องกัน Merge Conflict ในทีม
|
|
68
|
-
- ระบบ Auto-Cleanup ลบ Branch State หลังจบ `/complete` และย้ายเข้าสู่ History
|
|
69
|
-
- **✂️ Milestone 4: JIT Context Slicing & Token Budgeting Engine**
|
|
70
|
-
- ปรับระบบส่ง Context ให้ AI ตาม Stage แบบไดนามิก ประหยัด Token 70%
|
|
71
|
-
- ควบคุมขนาด `project-overview.md` ไม่ให้เกินงบประมาณ Token
|
|
72
|
-
- **🔄 Milestone 5: Git Diff Reconciler & Self-Healing State**
|
|
73
|
-
- ตรวจจับความคลาดเคลื่อนระหว่างการแก้โค้ดของมนุษย์กับ Living Spec
|
|
74
|
-
- ระบบ Smart Reconciliation แจ้งเตือนและซิงค์สเปกอัตโนมัติ
|
|
75
|
-
- **🖥️ Milestone 6: IDE Native Extension & Visual Kanban Studio**
|
|
76
|
-
- ส่วนขยายบน VS Code / Antigravity Webview สำหรับควบคุม DevFlow ครบวงจรใน IDE
|
|
77
|
-
- **🤖 Milestone 7: Multi-Agent Swarm Orchestration & Semantic Code RAG**
|
|
78
|
-
- ระบบประสานงาน Subagents หลายตัว (Coder, QA, Auditor) ทำงานขนานกัน
|
|
79
|
-
- Local Dependency Graph & Semantic Code Search เพื่อดึงบริบทที่แม่นยำสูงสุด
|
|
48
|
+
## 5. Technology Stack & Constraints
|
|
49
|
+
|
|
50
|
+
- **Language / Framework**: [เช่น Node.js, TypeScript, Next.js / Express]
|
|
51
|
+
- **Database**: [เช่น SQLite, PostgreSQL]
|
|
52
|
+
- **Hosting / Deployment**: [เช่น Local CLI, Vercel, Render, Docker]
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# Contextual Help Playbook
|
|
2
|
+
|
|
3
|
+
**Universal Contextual Help & Playbook Protocol (`help`, `--help`, `-h`, `?`)**:
|
|
4
|
+
Whenever any skill or command is invoked with a help keyword or flag (e.g., `/bughunter help`, `bughunter --help`, `/archify -h`, `/check ?`, `/feature help`):
|
|
5
|
+
- **Execution Safety Gate**: DO NOT execute the skill's primary or mutating actions (do not launch scans/attacks, do not modify source code, and do not initialize new task runs).
|
|
6
|
+
- **Dynamic Workspace Inspection**: Read the target skill in the active adapter. Inspect only workspace files and selected references needed to tailor its examples; reuse current context.
|
|
7
|
+
- **Persistent HTML Playbook & Token-Saving Cache**:
|
|
8
|
+
- **Output Location & Light Theme Mandate**: Compile and persist the tailored playbook as a standalone, styled HTML report at `devflow/docs/playbooks/{skill}.html` adhering to the **Paper/Ink Light Theme Standard** (`data-theme="light"`, teal accent, ruler corner, terminal mockup UI, and a real diagram). Reuse `devflow/docs/playbooks/template.html` when present; otherwise build the standalone page using these conventions.
|
|
9
|
+
- **First Run**: Render the comprehensive 5W1H playbook in chat and write the complete HTML report to `devflow/docs/playbooks/{skill}.html`.
|
|
10
|
+
- **Subsequent Invocations (Delta Updates & Zero Token Bloat)**: If `devflow/docs/playbooks/{skill}.html` already exists:
|
|
11
|
+
- Inspect the existing HTML file and compute the diff/delta against the current repository state (e.g., new file paths, modified endpoints, or newly installed vendor assets).
|
|
12
|
+
- DO NOT repeat unchanged boilerplate or full static content in chat.
|
|
13
|
+
- Provide a concise **Delta Summary** in chat (highlighting what changed, new recommendations, or newly available commands).
|
|
14
|
+
- In-place update `devflow/docs/playbooks/{skill}.html` with the fresh timestamp and state.
|
|
15
|
+
- Provide a clickable link to the actual resolved output file using the active client's supported local-file link format.
|
|
16
|
+
- **Render the User-Friendly 5W1H Playbook**: Emit an easy-to-read, practical guide organized around the **5W 1H Framework** (rendered on initial run or updated in the HTML playbook):
|
|
17
|
+
1. **What (Concept & Capabilities)**: Clear, jargon-free summary of what this skill does, its core concept, and its bundled tools/capabilities.
|
|
18
|
+
2. **Why (Problems Solved & Key Benefits)**: The problems it solves, key advantages, and why you should use it instead of ad-hoc manual work.
|
|
19
|
+
3. **Who (Target Roles & Personas)**: Target audience or engineering role (e.g., Feature Developer, Senior QA, Security Auditor, Solo Dev, or Tech Lead).
|
|
20
|
+
4. **Where (Boundaries & Artifact Locations)**: Target workspace boundaries, affected directories, and generated artifact locations (e.g., `devflow/context/`, `devflow/discoveries/`, `findings.md`).
|
|
21
|
+
5. **When (Timing & Prerequisites/Next Steps)**:
|
|
22
|
+
- **Timing & Triggers**: Practical situations or milestones when this skill should be invoked.
|
|
23
|
+
- **Run Before (Prerequisites)**: What to check, prepare, or run beforehand to get the best result.
|
|
24
|
+
- **Run After (Next Steps)**: What DevFlow command or lifecycle stage should follow next (e.g., handing off to `/fix`, `/feature`, or `/complete`).
|
|
25
|
+
6. **How (Execution Lifecycle & Real Command Examples)**:
|
|
26
|
+
- **How It Works (Lifecycle)**: Simple, plain-language breakdown of the execution steps or phases.
|
|
27
|
+
- **Available Commands & Options**: Common sub-commands, arguments, and flags with brief explanations.
|
|
28
|
+
- **Safety, Guardrails & Precautions**: Operational boundaries, credential hygiene, read-only vs. mutating constraints, and explicit special safety constraints / precautions.
|
|
29
|
+
7. **Diagram Slot & Architecture Flow**:
|
|
30
|
+
- **Real Diagram Mandate**: MUST embed a real, verified vector SVG or interactive diagram reflecting actual skill lifecycle, state transitions, or threat models in Light Theme (`data-theme="light"`).
|
|
31
|
+
- **Thai Language & Legible Typography**: Architecture and flow diagrams must describe workflows and nodes in Thai language while preserving technical identifiers, paths, and commands in English. Typography must be sufficiently sized and legible for Thai script (Headers 13–14px, box content/descriptions 11–12px, line spacing 18–22px) to prevent tone marks and vowels from clipping or overlapping.
|
|
32
|
+
- **Strictly No Placeholders**: NEVER output empty placeholder cards, generic instruction text, or phrases like *"when invoking archify..."*. Every playbook must ship with a real visual architectural diagram.
|
|
33
|
+
- Always conclude the response with: `"Help menu displayed successfully"`.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
|