@fledge/workflow 0.2.0 → 0.3.0

package/README.md

@@ -0,0 +1,35 @@
+# @fledge/workflow
+
+Workflow skills for the [Fledge](https://github.com/fledge-build/fledge-build) development workflow. Provides agent skills that guide feature planning, brief creation, and lifecycle management.
+
+## Install
+
+```bash
+pnpm add -D @fledge/workflow
+```
+
+On install, skills are automatically copied into your project's `.claude/skills/` directory. The `@fledge/cli` binary is resolved via `npx` at runtime, no separate install needed.
+
+## Skills
+
+### `fledge-brief`
+
+Guides the agent through feature brief creation and lifecycle. Invoked directly:
+
+```
+/fledge-brief
+```
+
+The skill walks through:
+
+1. **New brief** -- gather context from completed briefs, define requirements, break down into tasks
+2. **Continue a brief** -- review progress, update tasks, revise scope
+3. **Complete a brief** -- write a summary, validate, and mark as done
+
+The skill uses `fledge brief` CLI commands for file operations and state transitions. All artifacts are plain markdown files with YAML frontmatter, stored in `.fledge/briefs/`.
+
+## Dependencies
+
+| Package       | Role                                                    |
+| ------------- | ------------------------------------------------------- |
+| `@fledge/cli` | Resolved via `npx` at runtime. Provides brief lifecycle commands, schema validation, and skill installation |

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@fledge/workflow",
   "type": "module",
-  "version": "0.2.0",
+  "version": "0.3.0",
   "author": "René Schapka",
   "license": "MIT",
   "files": [
@@ -13,8 +13,8 @@
   "engines": {
     "node": ">=24"
   },
-  "peerDependencies": {
-    "@fledge/cli": "^0.5.0"
+  "dependencies": {
+    "@fledge/cli": "^0.6.0"
   },
   "devDependencies": {
     "@antfu/eslint-config": "7.7.3",

package/skills/brief/SKILL.md

@@ -7,6 +7,8 @@ metadata:
   type: workflow
 ---
 
+All CLI commands below use `npx -y @fledge/cli` as the binary prefix (abbreviated as `fledge` in examples). Always use the full `npx -y @fledge/cli <command>` form when executing.
+
 ## Step 0: Determine intent
 
 Ask what the user wants to do, or infer from context. Present these options:
@@ -15,7 +17,7 @@ Ask what the user wants to do, or infer from context. Present these options:
 2. **Continue a brief** — pick up an existing brief. Proceed to Step 4.
 3. **Complete a brief** — wrap up a finished feature. Proceed to Step 5.
 
-If unclear, run `fledge brief list` to show current briefs and ask.
+If unclear, run `npx -y @fledge/cli brief list` to show current briefs and ask.
 
 ---
 
@@ -23,7 +25,7 @@ If unclear, run `fledge brief list` to show current briefs and ask.
 
 Before writing anything, build an understanding of what exists.
 
-1. Run `fledge brief list --status completed` to read summaries of completed features. Note anything relevant to the new feature.
+1. Run `npx -y @fledge/cli brief list --status completed` to read summaries of completed features. Note anything relevant to the new feature.
 2. Ask the user what they want to build. Keep it conversational, not a form. Aim to understand:
    - What is the user-facing change?
    - Why does it matter?
@@ -38,7 +40,7 @@ Proceed to Step 2.
 
 ## Step 2: Draft the brief
 
-Run `fledge brief create <name>` to create the brief directory.
+Run `npx -y @fledge/cli brief create <name>` to create the brief directory.
 
 Write the brief content into `brief.md`. The frontmatter is managed by the CLI. The markdown body should capture:
 
@@ -74,7 +76,7 @@ tasks:
 
 Order tasks by dependency: tasks that others depend on come first within their group.
 
-After writing tasks, run `fledge brief validate <name>` to confirm the brief is valid, then run `fledge brief start <name>` to transition to active.
+After writing tasks, run `npx -y @fledge/cli brief validate <name>` to confirm the brief is valid, then run `npx -y @fledge/cli brief start <name>` to transition to active.
 
 Present the complete brief and task list to the user for review before starting.
 
@@ -82,22 +84,22 @@ Present the complete brief and task list to the user for review before starting.
 
 ## Step 4: Continue a brief
 
-Run `fledge brief list` to show all briefs. If the user does not specify which brief, ask them to pick one.
+Run `npx -y @fledge/cli brief list` to show all briefs. If the user does not specify which brief, ask them to pick one.
 
-Run `fledge brief status <name>` to show progress. Read the brief and tasks files to understand the full context.
+Run `npx -y @fledge/cli brief status <name>` to show progress. Read the brief and tasks files to understand the full context.
 
 From here, the user may want to:
 - **Discuss a task** — talk through approach before implementing
 - **Update tasks** — mark tasks as done, add new tasks, reorder
 - **Revise the brief** — update scope or design decisions based on what was learned during implementation
 
-When updating task status, modify the `tasks.md` frontmatter directly, then run `fledge brief status <name>` to confirm the update.
+When updating task status, modify the `tasks.md` frontmatter directly, then run `npx -y @fledge/cli brief status <name>` to confirm the update.
 
 ---
 
 ## Step 5: Complete a brief
 
-Run `fledge brief status <name>` to verify all tasks are done.
+Run `npx -y @fledge/cli brief status <name>` to verify all tasks are done.
 
 If there are incomplete tasks, ask the user whether to:
 1. Mark remaining tasks as done (if they were completed outside this conversation)
@@ -108,4 +110,4 @@ Write a summary into the `brief.md` frontmatter `summary` field. The summary sho
 - What was built
 - Key decisions or patterns established that future features should know about
 
-Run `fledge brief complete <name>` to transition to completed. The CLI validates that all tasks are done and the summary is present.
+Run `npx -y @fledge/cli brief complete <name>` to transition to completed. The CLI validates that all tasks are done and the summary is present.