@itsflower/cli 0.1.4 → 0.1.5

package/package.json

@@ -1,43 +1,32 @@
 {
   "name": "@itsflower/cli",
-  "version": "0.1.4",
-  "description": "🌸 flower CLI — scaffold structured development workflows",
-  "keywords": [
-    "cli",
-    "flower",
-    "templates",
-    "workflow"
-  ],
-  "license": "MIT",
-  "repository": {
-    "type": "git",
-    "url": "https://github.com/itsflower/flower"
-  },
+  "version": "0.1.5",
   "bin": {
-    "flower": "./dist/main.js"
+    "flower": "./dist/main.ts"
   },
   "files": [
-    "dist",
-    "templates",
-    "skills",
-    "commands"
+    "dist"
   ],
   "type": "module",
-  "publishConfig": {
-    "access": "public"
+  "main": "./dist/main.ts",
+  "types": "./dist/main.d.ts",
+  "exports": {
+    ".": {
+      "types": "./dist/main.d.ts",
+      "import": "./dist/main.ts"
+    }
   },
   "scripts": {
-    "build": "tsup src/main.ts --format esm --shims",
-    "release": "bun run ../../scripts/release.ts",
-    "prepack": "npm run build && rm -f templates && cp -r ../../core/templates templates && rm -rf skills && cp -r ../../core/skills skills && rm -rf commands && cp -r ../../core/commands commands",
-    "postpack": "rm -rf templates && ln -s ../../core/templates templates && rm -rf skills commands"
+    "build": "bun build ./src/main.ts --outdir ./dist --target node",
+    "dev": "bun run ./src/main.ts",
+    "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "citty": "^0.2.1"
+    "@clack/prompts": "^1.2.0",
+    "citty": "^0.2.2"
   },
   "devDependencies": {
-    "@types/bun": "latest",
-    "tsup": "^8.5.1",
-    "typescript": "^5.7.0"
+    "@types/bun": "^1.3.12",
+    "typescript": "^6.0.2"
   }
 }

package/LICENSE

@@ -1,21 +0,0 @@
-MIT License
-
-Copyright (c) 2025 itsflower
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.

package/README.md

@@ -1,28 +0,0 @@
-# @itsflower/cli
-
-🌸 Scaffold structured development workflows in your project.
-
-## Usage
-
-```bash
-# With npx (Node.js)
-npx @itsflower/cli init
-
-# With bunx (Bun)
-bunx @itsflower/cli init
-```
-
-## Commands
-
-### `flower init`
-
-Initializes flower in your project by copying workflow templates to `.flower/templates/`:
-
-- `requirement.md` — Define the problem, scope, and acceptance criteria
-- `plan.md` — Break down work into ordered tasks with ACs
-- `journal.md` — Log decisions and discoveries during implementation
-- `review.md` — Post-implementation quality checklist and learnings
-
-## License
-
-MIT

package/commands/flower.md

@@ -1,5 +0,0 @@
-# flower workflow
-
-Start the `flower` workflow for the following request:
-
-> $DESCRIPTION

package/skills/flower/SKILL.md

@@ -1,40 +0,0 @@
----
-name: flower
-description: 4-phase structured development workflow. Use only when user mentions "flower workflow"
----
-
-# flower workflow
-
-## Workflow
-
-```mermaid
-flowchart TD
-    Start([User input]) --> F1[1. Clarify]
-    F1 --> F2[2. Plan]
-    F2 -- not feasible --> E1([End - rejected])
-    F2 -- feasible --> F3[3. Build]
-    F3 --> F4[4. Review]
-    F4 --> E2([End - completed])
-```
-
-## Phases
-
-| #   | Phase   | Reference                                      |
-| --- | ------- | ---------------------------------------------- |
-| 1   | Clarify | [references/clarify.md](references/clarify.md) |
-| 2   | Plan    | [references/plan.md](references/plan.md)       |
-| 3   | Build   | [references/build.md](references/build.md)     |
-| 4   | Review  | [references/review.md](references/review.md)   |
-
-## Document Convention
-
-Create a folder `.flower/quests/<datetime>--<short-description>/` when starting a new quest.
-
-- `<datetime>` uses `YYMMDD-HHmm` format — run `uv run scripts/current_datetime.py` to generate it
-- `<short-description>` is a kebab-case summary generated by the agent
-- Folder contains `requirement.md`, `plan.md`, `journal.md`, and `review.md` based on templates in `.flower/templates/`.
-
-## Rules
-
-- When a phase begins, print `Phase <number>:<name>` for the user to easily follow
-- Follow the workflow steps strictly. Do not skip or reorder steps.

package/skills/flower/references/build.md

@@ -1,96 +0,0 @@
-# Phase 3: Build
-
-Execute tasks from `plan.md` in order. Test each one. Mark it done. Repeat.
-
-## Workflow
-
-```mermaid
-flowchart TD
-    Start[plan.md] --> B1[Execute next task]
-    B1 --> B2[Test / Verify]
-    B2 --> C1{Pass?}
-    C1 -- no --> B3[Fix issue]
-    C1 -- yes --> B4[Mark task done ✓]
-    B3 --> B2
-    B4 --> B5[Log if noteworthy]
-    B5 --> C2{All tasks done?}
-    C2 -- no --> B1
-    C2 -- yes --> B6[Mark plan completed]
-    B6 --> End([Phase 4: Review])
-```
-
-## Input
-
-- `requirement.md`
-- `plan.md` with `status: in-progress`
-
-## Steps
-
-### 1. Execute task
-
-Read the task's Description, AC, and Approach. Investigate relevant code. Implement. Stay in scope.
-
-| Complexity   | Investigation       | Implementation          | Testing                  |
-| ------------ | ------------------- | ----------------------- | ------------------------ |
-| **Trivial**  | Quick scan          | Direct change           | Spot check               |
-| **Standard** | Read related files  | Follow approach in plan | Related test suite       |
-| **Complex**  | Deep codebase study | Incremental changes     | Full test suite + manual |
-
-### 2. Test
-
-Run relevant tests. Verify every AC passes. Fix failures before moving on. If unrelated tests were already failing, note in journal and leave them.
-
-### 3. Mark task done — do not skip
-
-**Immediately after tests pass**, check the checkbox in `plan.md`:
-
-```
-- [ ] Task title  →  - [x] Task title
-```
-
-This tracks resumable state. A task is not done until checked.
-
-### 4. Log if noteworthy
-
-Open `.flower/journal.md` (create from `templates/journal.md` on first use).
-
-Log only when the plan was **not** followed exactly:
-
-- Deviated from the planned approach
-- Made a non-obvious decision
-- Hit a problem and resolved it
-- Discovered something reusable
-- Added a new task
-
-Entry format:
-
-```markdown
-### [Short title]
-- **tags**: [keywords]
-- **scope**: [global | project:<name>]
-- **context**: [what you were doing]
-- **insight**: [why — the decision, deviation, or discovery]
-```
-
-Skip if the plan was followed exactly with no surprises.
-
-### 5. Mark plan as completed
-
-After all tasks are checked, verify:
-
-- [ ] All checkboxes checked
-- [ ] All ACs verified
-- [ ] All tests pass
-- [ ] No unintended side effects
-- [ ] Deviations captured in journal
-
-Then set `status: completed` in plan frontmatter.
-
-## Rules
-
-- Never skip testing
-- Never skip marking done — it tracks where to resume
-- One task at a time; don't expand scope mid-task
-- New work = new task in the plan, not an expansion of the current one
-- Follow plan order; skip ahead only when blocked
-- Don't fix unrelated issues — note them for a future quest

package/skills/flower/references/clarify.md

@@ -1,84 +0,0 @@
-# Phase 1: Clarify
-
-Clarify user requirements, clearly describing WHAT and WHY, **not** HOW.
-
-## Workflow
-
-```mermaid
-flowchart TD
-    Start([User input]) --> C1[Analyze]
-    C1 --> C2[Research]
-    C2 --> C3{Ambiguities resolved?}
-    C3 -- No --> C4[Ask for clarification]
-    C4 --> C1
-    C3 -- Yes --> C5[Create `requirement.md`]
-    C5 --> End([Proceed to Phase 2: Plan])
-```
-
-For each step, follow the instructions below **strictly**
-
-## Steps
-
-### Analyze
-
-Read user input word by word. Extract:
-
-- **Codebase keywords** → file names, modules, functions, endpoints, components mentioned — feed into codebase exploration
-- **Technology keywords** → libraries, frameworks, languages, tools, APIs mentioned — feed into documentation lookup
-- **Intent** → feature, bug fix, refactor, or enhancement
-- **Constraints** → explicit or implicit limitations
-- **Ambiguities** → anything with multiple interpretations — feed into clarification questions
-
-### Research
-
-Use extracted keywords to investigate before asking:
-
-- **Codebase** → grep, glob, read files, `repomix` — understand existing code, patterns, architecture
-- **Technology** → use MCPs (`context7`, ...), fetch - understand relevant docs for mentioned technologies
-- **External**: look up APIs, standards, or domain concepts the human referenced
-
-### Ask for clarification
-
-Only if ambiguities remain after research:
-
-| Rule            | Detail                                                 |
-| --------------- | ------------------------------------------------------ |
-| Provide options | Prefer choices, not open questions.                    |
-| Batch questions | Group related questions. Max 5 per round.              |
-| Be specific     | Reference concrete code, files, or behaviors.          |
-| Easy to answer  | Human answers in few words or picks option.            |
-| Show research   | Share what you found to give context to your question. |
-
-After each response, restart: analyze → research based on new info → evaluate remaining ambiguities, gaps.
-
-### Create `requirement.md`
-
-Template in `.flower/templates/requirement.md`.
-
-| Section                     | Content                                                             |
-| --------------------------- | ------------------------------------------------------------------- |
-| Problem                     | Who is affected, when, what goes wrong. 2–5 bullets. No solutions.  |
-| User Stories                | "As a [user], I want [action] so that [benefit]"                    |
-| Goals                       | Verifiable outcomes — each yes/no checkable                         |
-| Non-Goals                   | Explicitly excluded — anything someone might assume is in scope     |
-| Acceptance Criteria         | Given/When/Then — pass/fail testable, no subjective judgment        |
-| Constraints & Prerequisites | Hard limits (unchangeable) + external requirements for this feature |
-| Glossary                    | Domain-specific terms only. Skip if self-explanatory.               |
-
-## Validate
-
-- [ ] Every goal is concrete and verifiable
-- [ ] Every goal has at least one acceptance criterion
-- [ ] Scope boundaries are unambiguous
-- [ ] All ambiguities from Q&A are resolved in the document — none deferred
-- [ ] Constraints are realistic and compatible with each other
-
-## Rules
-
-- **Read before asking** — research first, ask only what you can't answer
-- **Every word matters** — read input thoroughly, don't skip anything
-- **Options over open-ended** — prefer always giving choices when asking
-- **Problem ≠ solution** — describe what's wrong, not how to fix it
-- **Non-Goals prevent scope creep** — put effort here
-- **Self-contained but concise** — a reader must understand the problem and success criteria without reading the codebase
-- **No assumptions** — ambiguities must be resolved through research or Q&A, never assumed

package/skills/flower/references/plan.md

@@ -1,104 +0,0 @@
-# Phase 2: Plan
-
-Research HOW to implement `requirement.md` — explore codebase, study docs, decide approach, produce `plan.md`.
-
-## Workflow
-
-Execute steps in order. Do not skip. Do not create `plan.md` until the condition is met.
-
-```mermaid
-flowchart TD
-    Start([requirement.md]) --> P1[Codebase explore]
-    P1 --> P2[Research external]
-    P2 --> C1{Unclear / incomplete / multiple approaches?}
-    C1 -- no --> P3[Ask for clarification]
-    P3 --> P1
-    C1 -- yes --> P4[Create plan.md]
-    P4 --> End([Proceed to Phase 3: Build])
-```
-
-## Steps
-
-### Codebase explore
-
-Search with goals and acceptance criteria from `requirement.md` as targets:
-
-- **Architecture** — modules, layers, data flow relevant to the requirement
-- **Patterns** — how similar features are built; conventions to follow
-- **Reuse** — what exists vs. what must be built
-
-Tools: grep, glob, read files, `repomix`.
-
-### Research external
-
-For every technology, library, or pattern in scope:
-
-- **Docs** — capabilities, limitations, API surface
-- **Best practices** — recommended approaches, common pitfalls
-- **Alternatives** — other libraries or patterns solving the same problem
-
-Tools: `context7`, fetch, web search.
-
-### Ask for clarification
-
-Triggered when the approach is unclear, incomplete, or has multiple valid paths. **Do not decide alone.**
-
-After receiving answers, loop back to **Codebase explore** to validate the clarified approach before proceeding.
-
-| Trigger                   | What to present                        |
-| ------------------------- | -------------------------------------- |
-| Multiple valid approaches | Each option with pros, cons, tradeoffs |
-| New library or dependency | What it does, why needed, alternatives |
-| Significant tradeoff      | What is gained vs. given up            |
-
-| Rule            | Detail                                               |
-| --------------- | ---------------------------------------------------- |
-| Provide options | Offer choices with tradeoffs, not open-ended queries |
-| Show research   | Share findings to give context                       |
-| Batch questions | Group related decisions. Max ~5 per round            |
-| Be specific     | Reference concrete code, libraries, or behaviors     |
-
-### Create `plan.md`
-
-Only proceed here when the approach is fully decided, covers 100% of requirements, and has a single clear path.
-
-Template in `.flower/templates/plan.md`. Set `status: in-progress`.
-
-| Section             | Content                                                             |
-| ------------------- | ------------------------------------------------------------------- |
-| Overview            | 2-3 sentences: what is being built, approach, key technical choices |
-| Technical Decisions | Non-obvious decisions. WHAT, WHY, alternatives considered           |
-| Tasks               | Ordered by dependency. One logical change per task                  |
-| Dependencies        | Internal and external. Skip if none                                 |
-| Risks & Mitigation  | Only risks that would change the plan. Skip if none                 |
-
-Each task must have:
-
-| Field       | Required | Content                                            |
-| ----------- | -------- | -------------------------------------------------- |
-| Description | Yes      | Clear imperative statement                         |
-| AC          | Yes      | Pass/fail verifiable criteria                      |
-| Approach    | Yes      | Concrete steps, files to touch, patterns to follow |
-| Blocked by  | No       | Task dependency                                    |
-
-If no viable approach exists → set `status: rejected`, fill `## Rejection Reason`. End workflow.
-
-## Validate
-
-- [ ] Every requirement goal maps to at least one task
-- [ ] Every acceptance criterion is covered by a task's AC
-- [ ] Tasks ordered by dependency
-- [ ] Each task has AC and Approach
-- [ ] Technical decisions grounded in codebase research
-- [ ] No compound tasks — split any "X and Y"
-
-## Rules
-
-- **Follow the workflow** — never skip steps or reorder them
-- **Research before deciding** — explore codebase and docs before forming an approach
-- **Loop on uncertainty** — if unclear after research, ask for clarification then re-explore; repeat until resolved
-- **Surface choices** — when multiple approaches exist, present them with tradeoffs; never pick silently
-- **New deps need approval** — never add a library to the plan without asking
-- **Decisions in the document** — every choice from Q&A must appear in Technical Decisions
-- **One task, one change** — if a description uses "and", split it
-- **Concrete over vague** — Approach must name files, functions, and patterns

package/skills/flower/references/review.md

@@ -1,94 +0,0 @@
-# Phase 4: Review
-
-Quality gate and delivery summary. Verify everything not covered by task-level testing: security, performance, project standards, and overall correctness.
-
-## Workflow (**STRICTLY ENFORCED**)
-
-```mermaid
-flowchart TD
-    Start([plan.md & journal.md]) --> S[Write delivery summary]
-    S --> CL[Run quality checklist]
-    CL --> CF{All checks pass?}
-    CF -- No --> Fix[Fix issues]
-    Fix --> CL
-    CF -- Yes --> Done([Mark review as completed])
-```
-
-## Input
-
-- `plan.md` with `status: completed` (all tasks checked)
-- `journal.md` (if entries exist)
-- Template: `.flower/templates/review.md`
-
-## Steps
-
-1. **Write delivery summary**
-
-   Create `review.md` from the template in the quest directory. Set `status: draft`.
-
-   **Scale guidance**: match depth to the quest's scope.
-
-   | Quest Size | Summary Length | Metrics              | Outcome Detail    |
-   | ---------- | -------------- | -------------------- | ----------------- |
-   | **Small**  | 2-3 sentences  | Skip if not measured | Brief outcome     |
-   | **Medium** | 3-5 sentences  | Key metrics only     | Outcome + context |
-   | **Large**  | 5-8 sentences  | Full metrics         | Detailed outcome  |
-
-   Write the summary covering:
-   - **What was delivered** — concrete deliverables (features, fixes, refactors), not process steps
-   - **Overall outcome** — did it meet the requirement's goals? Any goals partially met or adjusted?
-   - **Key metrics** — lines changed, test coverage delta, performance improvement, or other measurable results (when available and meaningful)
-   - **Notable deviations** — significant differences from the original plan, if any (reference journal for details)
-
-   The summary must be **self-contained** — someone reading only the review doc should understand what was delivered and whether it succeeded, without referring to the requirement, plan, or journal.
-
-2. **Run quality checklist**
-
-   Go through each item systematically. For each: verify → fix if needed → check off.
-   - [ ] **Dead code & unused files removed** — check for commented-out code, unused imports, orphaned files created during implementation, and temporary debug code
-   - [ ] **Project standards followed** — verify code style, file structure, naming conventions, and linting rules match the rest of the codebase
-   - [ ] **No security issues** — scan for hardcoded secrets, SQL injection, XSS, auth bypass, exposed internal errors, and overly permissive permissions
-   - [ ] **Performance acceptable** — check for N+1 queries, unnecessary re-renders, unbounded loops, large payloads, missing pagination, and missing indexes
-   - [ ] **All tests pass** — run the full relevant test suite (not just per-task tests from Phase 2); verify no regressions were introduced
-   - [ ] **Documentation up to date** — README, API docs, inline docs, and config examples reflect the changes (skip if no user-facing docs exist)
-
-   If fixing an issue requires code changes:
-   1. Make the fix
-   2. Re-run the **full checklist** from the top (a fix can introduce new issues)
-   3. Repeat until all items pass cleanly in a single run
-
-3. **Write memories**
-
-   Record knowledge gained during this quest for future retrieval. Each memory entry uses the structured format:
-
-   ```markdown
-   ### [Short actionable title — 5-12 words]
-
-   - **content**: [Detailed explanation with context and examples]
-   - **tags**: [comma-separated domain keywords]
-   - **scope**: [global | project:<name>]
-   ```
-
-   Skip if no meaningful knowledge was gained.
-
-4. **Mark review as completed** → set `status: completed` in frontmatter
-
-## Output
-
-- Completed `review.md` with `status: completed`
-- Summary of delivery shared with the human
-
-## Rules
-
-- **Summary stands alone** — a reader with no context must understand what was delivered and whether it succeeded
-- **Never skip quality checks** — they catch issues that slip through during implementation; rushing here undermines the entire workflow
-- **Full re-run after fixes** — if quality checks reveal issues requiring code changes, re-run the entire checklist afterward; partial re-checks miss cascading problems
-- **Don't gold-plate** — quality checks fix real issues, they do not refactor working code or add enhancements beyond the quest's scope
-- **Reference, don't repeat** — the summary may reference the plan or journal for details, but must not require them to be understood
-
-## Status Lifecycle
-
-| Status      | Meaning                                 |
-| ----------- | --------------------------------------- |
-| `draft`     | Initial creation, summary being written |
-| `completed` | Quality checks passed, quest done       |

package/skills/flower/scripts/current_datetime.py

@@ -1,3 +0,0 @@
-from datetime import datetime
-
-print(datetime.now().strftime("%y%m%d-%H%M"))

package/templates/journal.md

@@ -1,46 +0,0 @@
-<!-- Record knowledge and decisions during implementation. Write entries during work, not after.
-Each entry uses a structured format for future search and retrieval.
-
-Guidelines:
-- Write in plain language, not formal prose
-- Focus on WHY, not WHAT — the code shows what changed
-- Only record noteworthy events — if the plan was followed exactly, there is nothing to log
-- One entry per meaningful event — do not log routine changes
--->
-
-## Entries
-
-<!-- Each entry must use this structured format:
-
-### [Short actionable title]
-- **tags**: [comma-separated domain keywords for search]
-- **scope**: [global | project:<name>]
-- **context**: [What was being worked on]
-- **insight**: [The decision, discovery, or deviation — focus on WHY]
-
-Example:
-
-### Switched from LIKE queries to tsvector for product search
-- **tags**: postgresql, search, performance, indexing
-- **scope**: project:catalog
-- **context**: Implementing the search endpoint (Task 2 in plan). Initial ILIKE approach showed 650ms response on 100K rows.
-- **insight**: LIKE with leading wildcard forces sequential scans. tsvector + GIN index provides O(log n) lookup, bringing response time from 650ms to 12ms. Always use tsvector for full-text search at scale.
-
----
-
-### Input validation prevents DoS via long search queries
-- **tags**: security, validation, performance
-- **scope**: global
-- **context**: Testing edge cases on the search endpoint. 10,000-char query caused 3s parse time.
-- **insight**: Unbounded input length is both a performance risk and a DoS vector. Added 1-200 char validation returning HTTP 400. Always validate input length for text-processing endpoints.
--->
-
-## Deviations from Plan
-
-<!-- Summarize significant differences between the plan and what was actually implemented. Fill this in at the end by pulling from entries above.
-
-Format:
-| Planned | Actual | Reason |
-| ------- | ------ | ------ |
-| [Original approach] | [What was done instead] | [Why the change] |
--->