ai-workflow-init 1.2.4 → 1.3.0

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.
@@ -1,16 +1,19 @@
1
-
2
1
  ## Goal
3
- Generate a planning doc at `docs/ai/planning/feature-{name}.md` using the template, with minimal, actionable content aligned to the 4-phase workflow.
2
+
3
+ Generate a planning doc at `docs/ai/planning/feature-{name}.md` using the template, with minimal, actionable content aligned to the 4-phase workflow. Also initialize the implementation doc at `docs/ai/implementation/feature-{name}.md` based on the implementation template.
4
4
 
5
5
  ## Workflow Alignment
6
+
6
7
  - Provide brief status updates (1–3 sentences) before/after important actions.
7
8
  - For medium/large tasks, create todos (≤14 words, verb-led). Keep only one `in_progress` item.
8
9
  - Update todos immediately after progress; mark completed upon finish.
9
10
 
10
11
  ## Step 1: Clarify Scope (Focused Q&A Guidelines)
12
+
11
13
  Purpose: the agent MUST generate a short, numbered Q&A for the user to clarify scope; keep it relevant, avoid off-topic, and do not build a static question bank.
12
14
 
13
15
  Principles:
16
+
14
17
  - Quickly classify context: a) Micro-UI, b) Page/Flow, c) Service/API/Data, d) Cross-cutting.
15
18
  - Ask only what is missing to produce Goal, Tasks, Risks, and DoD. Keep to 3–7 questions.
16
19
  - Do not re-ask what the user already stated; if ambiguous, confirm briefly (yes/no or single choice).
@@ -18,62 +21,75 @@ Principles:
18
21
  - Answers may be a/b/c or free text; the agent is not required to present fixed option lists.
19
22
 
20
23
  Output format for Q&A:
24
+
21
25
  - Number questions sequentially starting at 1 (e.g., "1.", "2.").
22
26
  - Under each question, provide 2–4 suggested options labeled with lowercase letters + ")" (e.g., "a)", "b)").
23
27
  - Keep options short (≤7 words) and add an "other" when useful.
24
28
  - Example:
25
29
  1. UI library?
26
- a) TailwindCSS b) Bootstrap c) SCSS d) Other
30
+ a) TailwindCSS b) Bootstrap c) SCSS d) Other
27
31
 
28
32
  Scope checklist to cover (ask only missing items, based on context):
29
- 1) Problem & Users: the core problem and target user groups.
30
- 2) In-scope vs Out-of-scope: what is included and excluded (e.g., MVP, no i18n, no payments).
31
- 3) Acceptance Criteria (GWT): 2–3 key Given–When–Then scenarios.
32
- 4) Constraints & Dependencies: technical constraints, libraries, real API vs mock, deadlines, external deps.
33
- 5) Risks & Assumptions: known risks and key assumptions.
34
- 6) Tasks Overview: 3–7 high-level work items.
35
- 7) Definition of Done: completion criteria (build/test/docs/review).
33
+
34
+ 1. Problem & Users: the core problem and target user groups.
35
+ 2. In-scope vs Out-of-scope: what is included and excluded (e.g., MVP, no i18n, no payments).
36
+ 3. Acceptance Criteria (GWT): 2–3 key Given–When–Then scenarios.
37
+ 4. Constraints & Dependencies: technical constraints, libraries, real API vs mock, deadlines, external deps.
38
+ 5. Risks & Assumptions: known risks and key assumptions.
39
+ 6. Tasks Overview: 3–7 high-level work items.
40
+ 7. Definition of Done: completion criteria (build/test/docs/review).
36
41
 
37
42
  Adaptive behavior:
43
+
38
44
  - Always reduce questions to what is necessary; once Goal/Tasks/Risks/DoD can be written, stop asking.
39
45
  - Prioritize clarifying scope and acceptance criteria before implementation details.
40
46
  - If the user already specified items (framework, API/Mock, deadlines, etc.), confirm briefly only.
41
47
 
42
48
  Then collect inputs (after Q&A):
49
+
43
50
  - Feature name (kebab-case, e.g., `user-authentication`)
44
51
  - Short goal and scope
45
52
  - High-level tasks overview (3–7 items)
46
53
  - Definition of Done (build/test/review/docs)
47
54
 
48
55
  ## Step 2: Load Templates
56
+
49
57
  **Before creating docs, read the following files:**
58
+
50
59
  - `docs/ai/planning/feature-template.md` - Template structure to follow
60
+ - `docs/ai/implementation/feature-template.md` - Template structure to follow for the implementation doc
51
61
 
52
62
  This template defines the required structure and format. Use it as the baseline for creating the planning doc.
53
63
 
54
64
  ## Step 3: Draft the Plan (auto-generate)
65
+
55
66
  Using the Q&A results and templates, immediately generate the plan without asking for confirmation.
56
67
 
57
68
  Auto-name feature:
69
+
58
70
  - Derive `feature-{name}` from user prompt + Q&A (kebab-case, concise, specific).
59
71
  - Example: "Login Page (HTML/CSS)" → `feature-login-page`.
60
72
  - If a file with the same name already exists, append a numeric suffix: `feature-{name}-2`, `feature-{name}-3`, ...
61
73
 
62
- Create the following file automatically and populate initial content:
74
+ Create the following files automatically and populate initial content:
75
+
63
76
  - `docs/ai/planning/feature-{name}.md` - Use structure from `feature-template.md`
77
+ - `docs/ai/implementation/feature-{name}.md` - Use structure from `docs/ai/implementation/feature-template.md` (read this template before writing)
64
78
 
65
- Do NOT create the implementation or testing files at this step.
66
79
  Notify the user when done.
67
80
 
68
81
  Produce a Markdown doc following the template structure:
82
+
69
83
  - Match sections from `docs/ai/planning/feature-template.md`
70
84
  - Fill in content from Q&A inputs
71
85
  - Ensure all required sections are present
72
86
 
73
87
  ## Step 4: Next Actions
74
- Suggest running `execute-plan` to begin task execution.
88
+
89
+ Suggest running `execute-plan` to begin task execution. Implementation work will be driven from `docs/ai/implementation/feature-{name}.md` as the task source.
75
90
  Note: Test documentation will be created separately using the `writing-test` command.
76
91
 
77
92
  ## Notes
78
- - This command creates planning docs only; does not modify unrelated existing files.
79
- - Idempotent: safe to re-run; auto-appends numeric suffix if file exists.
93
+
94
+ - This command creates the planning doc and initializes the implementation doc; it does not modify unrelated existing files.
95
+ - Idempotent: safe to re-run; auto-appends numeric suffix if files exist.
@@ -1,68 +1,83 @@
1
1
  ## Goal
2
- Execute the feature plan by implementing tasks and persisting notes to docs.
2
+
3
+ Execute the feature plan by implementing tasks from the implementation doc and persisting notes to docs.
3
4
 
4
5
  ## Workflow Alignment
6
+
5
7
  - Provide brief status updates (1–3 sentences) before each operation.
6
8
  - For medium/large tasks, create todos (≤14 words, verb-led). Keep only one `in_progress` item.
7
9
  - Update todos immediately after progress; mark completed upon finish.
8
10
  - Perform edits via file editing tools, not by printing code for copy-paste.
9
11
 
10
12
  ### Prerequisites
13
+
11
14
  - Feature name (kebab-case, e.g., `user-authentication`)
12
- - Planning doc exists: `docs/ai/planning/feature-{name}.md`
15
+ - Implementation doc exists: `docs/ai/implementation/feature-{name}.md`
16
+ - Planning doc exists: `docs/ai/planning/feature-{name}.md` (reference only; tasks are driven by implementation doc)
13
17
 
14
18
  ## Step 1: Gather Context
19
+
15
20
  - Ask for feature name if not provided (must be kebab-case).
16
- - Load plan: `docs/ai/planning/feature-{name}.md`.
21
+ - Load implementation doc: `docs/ai/implementation/feature-{name}.md`.
17
22
  - **Load template:** Read `docs/ai/implementation/feature-template.md` to understand required structure.
18
- - Ensure implementation doc exists or will be created: `docs/ai/implementation/feature-{name}.md`.
19
23
 
20
24
  ## Step 2: Build Task Queue
21
- - Parse tasks (checkboxes `[ ]`, `[x]`) from the plan.
25
+
26
+ - Parse tasks (checkboxes `[ ]`, `[x]`) from the implementation doc:
27
+ - Primary source: `## Changes` section with `[ ] [ACTION] ...` entries.
28
+ - For `[MODIFIED]` files, parse sub-bullets representing distinct logic items with line ranges.
29
+ - Optionally include other `[ ]` sections (e.g., `## Follow-ups`) if designated in-scope.
22
30
  - Build prioritized task queue (top-to-bottom unless dependencies block).
23
31
  - Identify blocked tasks and note reasons.
24
32
 
25
33
  ## Step 3: Implement Iteratively (per task)
34
+
26
35
  For each task in queue:
36
+
27
37
  1. **Status update**: Brief note (1–3 sentences) on what will be done.
28
38
  2. Plan minimal change set:
29
39
  - Identify files/regions to modify
30
- - Map changes to acceptance criteria from plan
40
+ - Map changes to acceptance criteria from plan (reference if needed)
31
41
  3. Implement changes:
32
- - Write/edit code according to the plan
42
+ - Write/edit code according to the implementation doc entries (`[ACTION]` items)
33
43
  - Keep changes minimal and incremental
34
- - Avoid speculative changes beyond plan scope
44
+ - Avoid speculative changes beyond implementation scope
35
45
  4. Quick validation:
36
46
  - Run build/compile if available
37
47
  - Run fast unit/smoke tests if available
38
48
  - Fix immediate issues before proceeding
39
49
  5. Persist notes to implementation doc:
40
50
  - File: `docs/ai/implementation/feature-{name}.md`
41
- - Append entry per completed task:
42
- - Files touched: `path/to/file.ext` (lines: x–y)
43
- - Approach/pattern used: brief description
44
- - Edge cases handled: list if any
45
- - Risks/notes: any concerns
46
- 6. Update planning doc:
47
- - Mark completed tasks `[x]` with brief note
51
+ - Update the relevant `[ ]` entry to `[x]` when completed
52
+ - For `MODIFIED` files with sub-bullets, mark each completed sub-bullet `[x]`
53
+ - Include line ranges and concise summaries as per template
54
+ 6. Update implementation doc:
55
+ - Mark completed tasks `[x]` with brief notes
48
56
  - Mark blocked tasks with reason
57
+ - Do not mirror completion state in the planning doc
49
58
 
50
59
  ## Step 4: Implementation Doc Structure
60
+
51
61
  **Before creating the implementation doc, ensure you have read:**
62
+
52
63
  - `docs/ai/implementation/feature-template.md` - Template structure to follow
53
64
 
54
- If creating implementation doc for first task:
65
+ If creating implementation doc for the first task (should already exist from create-plan):
66
+
55
67
  - Use the structure from `feature-template.md` exactly
56
- - Create `docs/ai/implementation/feature-{name}.md` with:
68
+ - Ensure these sections exist:
57
69
  - `# Implementation Notes: {Feature Name}`
58
70
  - `## Summary` - Brief description of overall approach
59
- - `## Changes` - Per-task entries with file paths, line ranges, approach
71
+ - `## Changes` Use `[ ] [ACTION] ...` format with allowed actions ADDED | MODIFIED | DELETED | RENAMED
72
+ - For MODIFIED, use sub-bullets with line ranges and per-logic summaries
60
73
  - `## Edge Cases` - List of handled edge cases
61
74
  - `## Follow-ups` - TODOs or deferred work
62
- - Follow the template format strictly
75
+ - `## Execution Discipline`
63
76
 
64
77
  ## Step 5: Quality Checks
78
+
65
79
  After completing Step 4 for each task batch:
80
+
66
81
  - Detect available tools from project config (e.g., `package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, build files) and run the appropriate non-interactive checks.
67
82
  - Linting on changed files (prefer non-interactive):
68
83
  - JavaScript/TypeScript: `npx eslint .` or `pnpm eslint .` (add `--max-warnings=0` if desired)
@@ -78,14 +93,17 @@ After completing Step 4 for each task batch:
78
93
  - Parallelize lint and type-check when safe; fix issues (up to 3 attempts) before proceeding.
79
94
 
80
95
  ## Step 6: Next Actions
96
+
81
97
  After completing tasks:
98
+
82
99
  - Suggest running `code-review` to verify against standards
83
100
  - Suggest running `writing-test` if edge cases need coverage
84
- - Suggest running `check-implementation` to validate alignment with plan
101
+ - Suggest running `check-implementation` to validate alignment with implementation entries
85
102
 
86
103
  ## Notes
87
- - Keep code changes minimal and focused on plan tasks
88
- - Document all changes in implementation doc for later review/refactor
89
- - Avoid implementing features not in the plan
90
- - Modifies source code per plan scope; updates `docs/ai/implementation/feature-{name}.md` and checkboxes in `docs/ai/planning/feature-{name}.md`. Does not modify unrelated files.
91
- - Idempotent: safe to re-run; appends entries or updates checkboxes deterministically.
104
+
105
+ - Keep code changes minimal and focused on implementation tasks
106
+ - Document all changes in the implementation doc; use checkboxes to track progress
107
+ - Avoid implementing features not in the implementation doc scope
108
+ - Modifies source code per implementation scope; updates `docs/ai/implementation/feature-{name}.md`. Does not modify unrelated files.
109
+ - Idempotent: safe to re-run; updates checkboxes deterministically.
@@ -1,19 +1,36 @@
1
1
  ## Goal
2
+
2
3
  Generate or update `docs/ai/project/CODE_CONVENTIONS.md` and `PROJECT_STRUCTURE.md` from the current codebase with brief Q&A refinement.
3
4
 
4
- ## Step 1: Clarify Scope (3–6 questions max)
5
+ ## Step 1: Detect Project Context
6
+
7
+ Detect project languages/frameworks/libraries from repository metadata:
8
+
9
+ - Analyze `package.json`, `pyproject.toml`, lockfiles, config files
10
+ - Identify primary languages (JavaScript/TypeScript, Python, etc.)
11
+ - Identify frameworks (React, Vue, Angular, etc.)
12
+ - Identify libraries and tooling (ESLint, Prettier, testing frameworks, etc.)
13
+ - Note any build tools or bundlers in use
14
+
15
+ **Output**: The detected project context will be written to `CODE_CONVENTIONS.md` as the foundation for code conventions.
16
+
17
+ ## Step 2: Clarify Scope (3–6 questions max)
18
+
5
19
  Quick classification and targeted questions:
20
+
6
21
  - Languages/frameworks detected: confirm correct? (a/b/other)
7
- - Import/style tools in use: (a) ESLint/Prettier (b) Other formatter (c) None
8
- - Test placement preference: (a) Colocated `*.spec.*` (b) `__tests__/` directory (c) Other
9
- - Error handling strategy: (a) Exceptions/try-catch (b) Result types (c) Other
10
- - Module organization: (a) By feature (b) By layer (c) Mixed
22
+ - Import/style tools in use: (a) ESLint/Prettier (b) Other formatter (c) None
23
+ - Test placement preference: (a) Colocated `*.spec.*` (b) `__tests__/` directory (c) Other
24
+ - Error handling strategy: (a) Exceptions/try-catch (b) Result types (c) Other
25
+ - Module organization: (a) By feature (b) By layer (c) Mixed
11
26
  - Any performance/security constraints to encode? (yes/no, brief)
12
27
 
13
28
  Keep questions short and single-purpose. Stop once sufficient info gathered.
14
29
 
15
- ## Step 2: Auto-Discovery
30
+ ## Step 3: Auto-Discovery
31
+
16
32
  Analyze repository to infer:
33
+
17
34
  - Dominant naming patterns:
18
35
  - Variables/functions: camelCase/PascalCase/snake_case
19
36
  - Classes/types: PascalCase
@@ -33,16 +50,26 @@ Analyze repository to infer:
33
50
  - Strategy patterns
34
51
  - Other architectural patterns
35
52
 
36
- ## Step 3: Draft Standards
53
+ ## Step 4: Draft Standards
54
+
37
55
  Generate two documents (with template preload):
38
56
 
39
57
  ### CODE_CONVENTIONS.md
40
- - Template preload (in order, if present):
41
- 1) `docs/ai/project/template-convention/common.md` always preload first.
42
- 2) `docs/ai/project/template-convention/javascript.md` — preload if the repository primarily uses JavaScript/TypeScript.
43
- 3) `docs/ai/project/template-convention/react.md` — preload if the repository uses React (detect via dependencies like `react`, file patterns like `.jsx/.tsx`, or imports from `react`).
44
-
45
- These templates take precedence and should appear at the top of the generated document, followed by auto-discovered rules.
58
+
59
+ - Template preload (flexible matching based on detected project context):
60
+
61
+ 1. Read all files in `docs/ai/project/template-convention/` directory
62
+ 2. For each template file, determine if it matches the detected project context:
63
+ - Match by language (e.g., `javascript.md`, `typescript.md`, `python.md`)
64
+ - Match by framework (e.g., `react.md`, `vue.md`, `angular.md`)
65
+ - Match by common patterns (e.g., `common.md` — always include if present)
66
+ 3. Load and merge all matching templates in a logical order:
67
+ - `common.md` first (if present)
68
+ - Language-specific templates (e.g., `javascript.md`, `typescript.md`)
69
+ - Framework-specific templates (e.g., `react.md`, `vue.md`)
70
+ - Other relevant templates based on detected tooling/patterns
71
+ 4. These templates take precedence and should appear at the top of the generated document, followed by auto-discovered rules from codebase analysis.
72
+
46
73
  - Naming conventions (variables, functions, classes, constants)
47
74
  - Import order and grouping
48
75
  - Formatting tools (ESLint/Prettier/etc.) if detected
@@ -53,6 +80,7 @@ Generate two documents (with template preload):
53
80
  - Async/await patterns if applicable
54
81
 
55
82
  ### PROJECT_STRUCTURE.md
83
+
56
84
  - Folder layout summary:
57
85
  - `src/`: source code organization
58
86
  - `docs/ai/**`: documentation structure
@@ -61,7 +89,8 @@ Generate two documents (with template preload):
61
89
  - Test placement and naming conventions
62
90
  - Config/secrets handling summary
63
91
 
64
- ## Step 4: Persist (Update-in-place, Non-destructive)
92
+ ## Step 5: Persist (Update-in-place, Non-destructive)
93
+
65
94
  - Target files:
66
95
  - `docs/ai/project/CODE_CONVENTIONS.md`
67
96
  - `docs/ai/project/PROJECT_STRUCTURE.md`
@@ -69,12 +98,15 @@ Generate two documents (with template preload):
69
98
  - Do NOT blindly overwrite entire files. Update only the managed blocks using markers:
70
99
 
71
100
  ### Managed Block Markers
101
+
72
102
  Use these exact markers to wrap generated content:
103
+
73
104
  ```
74
105
  <!-- GENERATED: CODE_CONVENTIONS:START -->
75
106
  ... generated content ...
76
107
  <!-- GENERATED: CODE_CONVENTIONS:END -->
77
108
  ```
109
+
78
110
  ```
79
111
  <!-- GENERATED: PROJECT_STRUCTURE:START -->
80
112
  ... generated content ...
@@ -82,25 +114,29 @@ Use these exact markers to wrap generated content:
82
114
  ```
83
115
 
84
116
  ### Update Rules
85
- 1) If the target file exists and contains the corresponding markers, replace only the content between START/END with the newly generated content.
86
- 2) If the file exists but does not contain markers, append a new managed block to the end of the file (preserve all existing manual content).
87
- 3) If the file does not exist, create it with the header note and a single managed block.
88
- 4) Never modify content outside the managed blocks.
117
+
118
+ 1. If the target file exists and contains the corresponding markers, replace only the content between START/END with the newly generated content.
119
+ 2. If the file exists but does not contain markers, append a new managed block to the end of the file (preserve all existing manual content).
120
+ 3. If the file does not exist, create it with the header note and a single managed block.
121
+ 4. Never modify content outside the managed blocks.
89
122
 
90
123
  ### Generated Content Order (for CODE_CONVENTIONS)
91
- - Merge templates in preload order (when present):
92
- 1) `docs/ai/project/template-convention/common.md`
93
- 2) `docs/ai/project/template-convention/javascript.md` (when JS/TS detected)
94
- 3) `docs/ai/project/template-convention/react.md` (when React is detected)
95
- 4) `docs/ai/project/template-convention/typescript.md.md` (when TS is detected)
96
- - After the merged templates, append auto-discovered rules from the codebase analysis.
97
-
98
- ## Step 5: Next Actions
124
+
125
+ 1. **Project Context Section**: Write the detected project context from Step 1 (languages, frameworks, libraries, tooling)
126
+ 2. **Template Rules Section**: Merge all matching templates from `docs/ai/project/template-convention/` directory:
127
+ - Read all files in the directory
128
+ - Filter templates that match the detected project context (by language, framework, or common patterns)
129
+ - Merge in logical order: common language framework tooling-specific
130
+ 3. **Auto-Discovered Rules Section**: Append auto-discovered rules from codebase analysis (Step 3)
131
+ 4. **Project-Specific Rules Section**: Include any project-specific conventions from Q&A (Step 2)
132
+
133
+ ## Step 6: Next Actions
134
+
99
135
  - Suggest running `code-review` to validate new standards are being followed
100
136
  - Inform user they can manually edit these files anytime
101
137
 
102
138
  ## Notes
139
+
103
140
  - Focus on patterns actually present in codebase, not ideal patterns
104
141
  - Keep generated docs concise and actionable
105
142
  - User can refine standards manually after generation
106
-
@@ -1,30 +1,33 @@
1
1
  ## Goal
2
+
2
3
  Initialize a new chat by loading and aligning to `AGENTS.md` so the AI agent consistently follows project rules (workflow, tooling, communication, language mirroring) from the first message.
3
4
 
4
5
  ## What this command does
6
+
5
7
  1. Read `AGENTS.md` and extract the actionable rules.
6
8
  2. Summarize responsibilities and constraints the agent must follow in this session.
7
9
  3. Confirm language-mirroring: respond in the user's chat language; default to English if the user's language is unclear or ambiguous.
8
10
  4. Acknowledge the 4-phase workflow and TODO discipline for future commands.
9
11
 
10
12
  ## Steps
11
- 1) Open and read `AGENTS.md` (project root).
12
- 2) Detect project languages/frameworks/libraries from repository metadata (e.g., `package.json`, `pyproject.toml`, lockfiles, config files). If `docs/ai/project/CODE_CONVENTIONS.md` is missing, create a minimal generated stub capturing key conventions (e.g., React, TypeScript, TailwindCSS). If it already exists, do not modify; instead, report any detected gaps and suggest running the standards generator.
13
- 3) Read files in `docs/ai/project/` to understand project context and standards.
14
- 4) Produce a short confirmation in the chat including:
13
+
14
+ 1. Open and read `AGENTS.md` (project root).
15
+ 2. Read `docs/ai/project/CODE_CONVENTIONS.md` and `docs/ai/project/PROJECT_STRUCTURE.md` if they exist in the repository.
16
+ 3. Produce a short confirmation in the chat including:
15
17
  - Workflow alignment: Plan → Implement → Test → Review
16
18
  - Tooling strategy: semantic search first; parallelize independent steps
17
19
  - Communication: minimal Markdown; status updates; high-signal summaries; mirror user language (default English if unclear)
18
20
  - Code presentation: code references for existing code; fenced blocks for new code
19
21
  - TODO policy: create/update todos; keep only one `in_progress`
20
- 5) If any section is missing or unclear, ask a single concise clarification question; otherwise proceed silently in future commands.
22
+ 4. If any section is missing or unclear, ask a single concise clarification question; otherwise proceed silently in future commands.
21
23
 
22
24
  ## Output format (concise)
25
+
23
26
  - Use the language of the triggering user message (mirror). If ambiguous, use English.
24
27
  - One short paragraph confirming alignment + a 4–6 bullet checklist of the above items.
25
28
  - No code unless strictly needed.
26
29
 
27
30
  ## Notes
28
- - This command is idempotent—safe to re-run at the start of any chat.
29
- - It does not modify existing files; it only sets expectations for subsequent commands and may create missing metadata files (e.g., initial `CODE_CONVENTIONS.md`) if required.
30
31
 
32
+ - This command is idempotent—safe to re-run at the start of any chat.
33
+ - It does not modify existing files; it only sets expectations for subsequent commands.
package/cli.js CHANGED
@@ -1,48 +1,98 @@
1
1
  #!/usr/bin/env node
2
2
 
3
- const { execSync } = require('child_process');
4
- const { existsSync, mkdirSync } = require('fs');
3
+ const { execSync } = require("child_process");
4
+ const { existsSync, mkdirSync } = require("fs");
5
+ const readline = require("readline");
5
6
 
6
7
  // Repo workflow gốc của bạn
7
- const REPO = 'phananhtuan09/ai-agent-workflow';
8
- const RAW_BASE = 'https://raw.githubusercontent.com/phananhtuan09/ai-agent-workflow/main';
8
+ const REPO = "phananhtuan09/ai-agent-workflow";
9
+ const RAW_BASE =
10
+ "https://raw.githubusercontent.com/phananhtuan09/ai-agent-workflow/main";
9
11
 
10
12
  // In ra helper log
11
13
  function step(msg) {
12
- console.log('\x1b[36m%s\x1b[0m', msg); // cyan
14
+ console.log("\x1b[36m%s\x1b[0m", msg); // cyan
13
15
  }
14
16
 
15
17
  function run(cmd) {
16
18
  try {
17
- execSync(cmd, { stdio: 'inherit' });
19
+ execSync(cmd, { stdio: "inherit" });
18
20
  } catch (e) {
19
- console.error('❌ Failed:', cmd);
21
+ console.error("❌ Failed:", cmd);
20
22
  process.exit(1);
21
23
  }
22
24
  }
23
25
 
24
- // Kiểm tra tạo folder nếu chưa có
25
- if (!existsSync('docs/ai')) {
26
- mkdirSync('docs/ai', { recursive: true });
27
- }
28
- if (!existsSync('.cursor/commands')) {
29
- mkdirSync('.cursor/commands', { recursive: true });
26
+ // Hỏi user chọn IDE
27
+ const rl = readline.createInterface({
28
+ input: process.stdin,
29
+ output: process.stdout,
30
+ });
31
+
32
+ function askIDE() {
33
+ return new Promise((resolve) => {
34
+ console.log("\n🤖 Which AI tool(s) do you want to setup?");
35
+ console.log("1. Cursor");
36
+ console.log("2. GitHub Copilot");
37
+ console.log("3. Both");
38
+
39
+ rl.question("\nEnter your choice (1-3): ", (answer) => {
40
+ rl.close();
41
+ resolve(answer.trim());
42
+ });
43
+ });
30
44
  }
31
45
 
32
- step('🚚 Downloading workflow template (docs/ai)...');
33
- run(`npx degit ${REPO}/docs/ai docs/ai --force`);
46
+ async function main() {
47
+ const choice = await askIDE();
48
+ const installCursor = ["1", "3"].includes(choice);
49
+ const installCopilot = ["2", "3"].includes(choice);
50
+
51
+ if (!["1", "2", "3"].includes(choice)) {
52
+ console.error("❌ Invalid choice. Please enter 1, 2, or 3.");
53
+ process.exit(1);
54
+ }
55
+
56
+ // Kiểm tra và tạo folder nếu chưa có
57
+ if (!existsSync("docs/ai")) {
58
+ mkdirSync("docs/ai", { recursive: true });
59
+ }
34
60
 
35
- step('🚚 Downloading agent commands (.cursor/commands)...');
36
- run(`npx degit ${REPO}/.cursor/commands .cursor/commands --force`);
61
+ step("🚚 Downloading workflow template (docs/ai)...");
62
+ run(`npx degit ${REPO}/docs/ai docs/ai --force`);
63
+
64
+ // Clone Cursor commands
65
+ if (installCursor) {
66
+ if (!existsSync(".cursor/commands")) {
67
+ mkdirSync(".cursor/commands", { recursive: true });
68
+ }
69
+ step("🚚 Downloading Cursor agent commands (.cursor/commands)...");
70
+ run(`npx degit ${REPO}/.cursor/commands .cursor/commands --force`);
71
+ }
72
+
73
+ // Clone GitHub Copilot commands (nếu có folder khác)
74
+ if (installCopilot) {
75
+ if (!existsSync(".copilot/commands")) {
76
+ mkdirSync(".copilot/commands", { recursive: true });
77
+ }
78
+ step("🚚 Downloading GitHub Copilot agent commands (.copilot/commands)...");
79
+ run(`npx degit ${REPO}/.copilot/commands .copilot/commands --force`);
80
+ }
81
+
82
+ step("🚚 Downloading AGENTS.md ...");
83
+ try {
84
+ run(`curl -fsSL ${RAW_BASE}/AGENTS.md -o AGENTS.md`);
85
+ } catch (_) {
86
+ // Fallback cho môi trường không có curl
87
+ run(`wget -qO AGENTS.md ${RAW_BASE}/AGENTS.md`);
88
+ }
37
89
 
38
- step('🚚 Downloading AGENTS.md ...');
39
- // degit không hỗ trợ tải 1 file đơn lẻ -> dùng raw github
40
- try {
41
- run(`curl -fsSL ${RAW_BASE}/AGENTS.md -o AGENTS.md`);
42
- } catch (_) {
43
- // Fallback cho môi trường không có curl
44
- run(`wget -qO AGENTS.md ${RAW_BASE}/AGENTS.md`);
90
+ step(
91
+ "✅ All AI workflow docs and selected command templates have been copied!"
92
+ );
93
+ console.log(
94
+ "\n🌱 You can now use your AI workflow! Edit docs/ai/ and AGENTS.md as needed.\n"
95
+ );
45
96
  }
46
97
 
47
- step('✅ All AI workflow docs, command templates, and AGENTS.md have been copied!');
48
- console.log('\n🌱 You can now use your AI workflow! Edit docs/ai/ and AGENTS.md as needed.\n');
98
+ main();
@@ -3,19 +3,29 @@
3
3
  Note: All content in this document must be written in English.
4
4
 
5
5
  ## Summary
6
+
6
7
  - Short description of the solution approach
7
8
 
8
9
  ## Changes
9
- - File: path/to/file1 (lines: x–y) — solution/ API/ pattern
10
- - File: path/to/file2 (lines: ab) — change summary
10
+
11
+ - [ ] [ACTION] path/to/file (lines: xy) — Summary of change
12
+ - [ ] [ACTION] path/to/file (lines: a–b) — Summary of change
13
+
14
+ Notes:
15
+
16
+ - ACTION must be one of: ADDED | MODIFIED | DELETED | RENAMED
17
+ - For MODIFIED files, use sub-bullets for each distinct logic change and include line ranges.
11
18
 
12
19
  ## Edge Cases
20
+
13
21
  - List of handled edge cases
14
22
 
15
23
  ## Follow-ups
24
+
16
25
  - TODOs or deferred work
17
26
 
18
27
  ## Execution Discipline
28
+
19
29
  - Before each edit, provide a short status update describing the next action (1–3 sentences).
20
30
  - Perform edits via file editing tools; avoid printing large code blocks for copy-paste.
21
31
  - After each batch of edits, run linter/type/build on changed files; auto-fix issues (up to 3 attempts) before requesting review.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "ai-workflow-init",
3
- "version": "1.2.4",
3
+ "version": "1.3.0",
4
4
  "description": "Initialize AI workflow docs & commands into any repo with one command",
5
5
  "bin": {
6
6
  "ai-workflow-init": "./cli.js"