agileflow 4.0.0-alpha.2 → 4.0.0-alpha.21

package/content/plugins/delivery/skills/agileflow-delivery/workflows/changelog.md

@@ -0,0 +1,72 @@
+# Changelog Workflow — Auto-Generate Changelog
+
+**Triggers:** "generate changelog", "update CHANGELOG.md", "what changed since last release", "changelog for v2.5.0", "write release notes"
+
+**Goal:** Parse git commits since the last tag, categorize changes by type, suggest a semantic version bump, generate a Keep a Changelog section, and update `CHANGELOG.md` after user confirmation.
+
+## Inputs needed
+
+| Input   | Required | How to get it                                   |
+| ------- | -------- | ----------------------------------------------- |
+| version | No       | Auto-detect from latest git tag if not provided |
+| since   | No       | Auto-detect last version tag if not provided    |
+| format  | No       | Default: Keep a Changelog                       |
+
+## Steps
+
+1. If the version is not provided, run `git describe --tags --abbrev=0` to find the latest tag. Use the next version as the target.
+
+2. Get all commits since the last tag: `git log <last-tag>..HEAD --oneline`.
+
+3. Parse conventional commits and categorize:
+   - `feat:` → **Added**
+   - `fix:` → **Fixed**
+   - `perf:` → **Changed** (performance improvement)
+   - `refactor:` → **Changed**
+   - `security:` → **Security**
+   - `!` suffix or `BREAKING CHANGE:` footer → **Changed** with a breaking change warning
+
+4. Suggest a semantic version bump based on what's present:
+   - BREAKING CHANGE → major bump
+   - `feat:` present → minor bump
+   - Only `fix:` / `chore:` → patch bump
+
+5. Generate the changelog section in Keep a Changelog format:
+
+   ```markdown
+   ## [X.Y.Z] - YYYY-MM-DD
+
+   ### Added
+
+   - feat: description (#PR)
+
+   ### Fixed
+
+   - fix: description (#PR)
+
+   ### Changed
+
+   - perf/refactor entries
+   ```
+
+6. Show the preview to the user. Ask: [A] Update `CHANGELOG.md` with this (recommended), [B] Adjust the version number, [C] Remove a specific entry, [D] Cancel.
+
+7. If confirmed, prepend the new section to `CHANGELOG.md`. Never remove existing entries.
+
+8. Ask: "Commit the changelog update?" Options: [A] Yes — `git add CHANGELOG.md && git commit -m "chore: update changelog for vX.Y.Z"`, [B] No, I'll commit it myself.
+
+## Output
+
+Updated `CHANGELOG.md` with the new version section at the top. Optional git commit. The version suggestion helps align with semantic versioning conventions.
+
+## Fallbacks
+
+**If interactive prompts (AskUserQuestion) are unavailable:**
+Present options as a numbered list in your response. Ask the user to reply with a number. Example:
+
+```
+How would you like to proceed?
+1. Save and continue
+2. Review before saving
+3. Discard
+```

package/content/plugins/delivery/skills/agileflow-delivery/workflows/deploy.md

@@ -0,0 +1,74 @@
+# Deploy Workflow — Deployment Pipeline Setup
+
+**Triggers:** "set up deployment", "configure CI/CD", "deploy to production", "I need a deployment pipeline", "configure Vercel/Netlify/Railway", "set up GitHub Actions for deploy"
+
+**Goal:** Auto-detect the project type, recommend a deployment platform, generate configuration files, and create a CI/CD workflow — all previewed before any files are written.
+
+## Inputs needed
+
+| Input           | Required | How to get it                     |
+| --------------- | -------- | --------------------------------- |
+| project type    | No       | Auto-detected from codebase       |
+| target platform | No       | Recommended based on project type |
+| environments    | No       | Default: staging + production     |
+
+## Steps
+
+1. Auto-detect the project type by inspecting the codebase:
+   - **Static**: `package.json` with only a build script, no server code
+   - **Full-stack**: Next.js API routes, Express, FastAPI, or similar
+   - **Mobile**: Expo config or react-native dependencies
+   - **Containers**: `Dockerfile` present
+   - **Serverless**: Lambda functions or `serverless.yml`
+     If unclear, ask: "Is this a static site, a full-stack app, a containerized app, or serverless?"
+
+2. Recommend a deployment platform based on the detected type:
+   - Next.js → **Vercel** (native Next.js support)
+   - React SPA / static → **Netlify** (built-in redirects, simple setup)
+   - Node.js server → **Railway** (cheap, Docker-based)
+   - Docker container → **Fly.io** (native container support)
+   - Expo/React Native → **EAS** (official Expo deployment)
+   - AWS preference → **Lambda + API Gateway**
+
+3. Ask the user: "I recommend [platform] for your [project type]. Proceed, or would you prefer a different platform?"
+
+4. Before creating any files, show a preview of everything that will be created:
+
+   ```
+   Deployment Setup for: [project type]
+   Platform: [platform]
+
+   Will create:
+   - [platform config file] (e.g., vercel.json, netlify.toml, Dockerfile)
+   - .github/workflows/deploy.yml (CI/CD pipeline)
+   - .env.example (secrets template — actual secrets are never committed)
+   - docs/02-practices/deployment.md (deployment guide)
+   ```
+
+5. Ask: [A] Create all files (recommended), [B] Create just the platform config, [C] Create just the CI/CD workflow, [D] Cancel.
+
+6. Generate the selected files:
+   - Platform config with staging and production environment separation
+   - GitHub Actions workflow that deploys on push to `main` (production) and PRs (staging preview)
+   - `.env.example` listing all required environment variables (no actual values)
+   - Brief deployment guide in docs
+
+7. List the secrets that need to be added to GitHub repository settings.
+
+8. Ask: [A] Show me how to add the secrets to GitHub, [B] I'll handle the secrets myself — just give me the list, [C] Run a test deployment now.
+
+## Output
+
+Platform config file. GitHub Actions workflow. `.env.example` template. Deployment guide. List of required secrets.
+
+## Fallbacks
+
+**If interactive prompts (AskUserQuestion) are unavailable:**
+Present options as a numbered list in your response. Ask the user to reply with a number. Example:
+
+```
+How would you like to proceed?
+1. Save and continue
+2. Review before saving
+3. Discard
+```

package/content/plugins/delivery/skills/agileflow-delivery/workflows/pr.md

@@ -0,0 +1,75 @@
+# PR Workflow — Pull Request Description Generator
+
+**Triggers:** "create a PR", "generate PR description", "I'm opening a pull request for US-XXXX", "write the PR body", "PR for this story"
+
+**Goal:** Generate a complete, paste-ready GitHub pull request description from the story file — including summary, linked issues, AC checklist, test evidence, and risk assessment.
+
+## Inputs needed
+
+| Input                  | Required | How to get it                                                                   |
+| ---------------------- | -------- | ------------------------------------------------------------------------------- |
+| story ID               | Yes      | Ask: "Which story is this PR for? (e.g., US-0042)"                              |
+| PR title               | No       | Defaults to story summary                                                       |
+| AC verification states | No       | Ask which ACs have been verified                                                |
+| test evidence          | No       | Ask: "Any test evidence to include? (file paths, screenshots, test run output)" |
+| notes                  | No       | Any additional context for the reviewer                                         |
+
+## Steps
+
+1. Ask for the story ID if not provided.
+
+2. Read the story file from `docs/06-stories/<STORY>.md`. Extract — never guess:
+   - Epic reference
+   - Story summary and full description
+   - Dependencies on other stories
+   - Acceptance criteria (exact text, in order)
+   - Owner/assignee
+
+3. Ask the user: "Which acceptance criteria have you verified?" Present the list of ACs and let them mark each as verified or pending.
+
+4. Ask: "Any test evidence to include? Paste test run output, file paths, or screenshot descriptions."
+
+5. Generate the PR description in GitHub markdown:
+
+   ```
+   ## <STORY>: <TITLE>
+
+   ### Summary
+   [2–3 paragraphs from story description + any user notes]
+
+   ### Linked Issues
+   - #<STORY>
+   - #<DEP1> (if dependencies exist)
+
+   ### Acceptance Criteria
+   - [x] Verified criterion
+   - [ ] Pending criterion
+
+   ### Test Evidence
+   [Formatted bullets with paths or links]
+
+   ### Risk Assessment
+   [Bullet list of potential risks + rollback approach]
+   ```
+
+6. Show the PR description for review. Ask the user: [A] This looks good — copy it, [B] Adjust the title, [C] Add more test evidence, [D] Change which ACs are checked.
+
+7. If the user wants to open the PR from the CLI, run `gh pr create` with the generated title and body. If not, the description is ready to paste into GitHub.
+
+8. Suggest the conventional commit type for the merge: `feat:` for new functionality, `fix:` for bug fixes, `chore:` for maintenance.
+
+## Output
+
+Paste-ready PR description in GitHub markdown. Optional: PR opened via `gh pr create`. Conventional commit type suggested.
+
+## Fallbacks
+
+**If interactive prompts (AskUserQuestion) are unavailable:**
+Present options as a numbered list in your response. Ask the user to reply with a number. Example:
+
+```
+How would you like to proceed?
+1. Save and continue
+2. Review before saving
+3. Discard
+```