agileflow 2.61.0 → 2.62.0

package/src/core/skills/agileflow-adr/SKILL.md

@@ -1,147 +0,0 @@
----
-name: agileflow-adr
-description: Detects architectural or technical decisions in conversations and formats them as Architecture Decision Records in docs/03-decisions/. Loads when discussing technology choices, architecture patterns, or trade-offs.
----
-
-# AgileFlow ADR (Architecture Decision Records)
-
-Automatically captures architectural and technical decisions and formats them as formal Architecture Decision Records (ADRs) in `docs/03-decisions/`.
-
-## When to Use
-
-This skill activates when:
-- Discussing technology choices ("Should we use PostgreSQL or MongoDB?")
-- Debating architecture patterns ("REST vs GraphQL")
-- Making framework decisions ("React vs Vue")
-- Discussing infrastructure choices ("AWS vs GCP")
-- Evaluating trade-offs between options
-- Keywords: "decision", "choose", "architecture", "trade-off"
-
-## What This Does
-
-1. Detects architectural decision discussions from conversations
-2. Asks clarifying questions if needed (context, options, constraints)
-3. Extracts decision elements (problem, options, drivers, trade-offs)
-4. Generates properly formatted ADR file
-5. Shows for approval before writing
-
-## Instructions
-
-1. **Detect decision discussion**: User is debating options or asking "which should we use?"
-
-2. **Extract decision elements**:
-   - Context/problem statement
-   - Options being considered
-   - Trade-offs for each option
-   - Decision drivers (requirements, constraints)
-
-3. **Read existing ADRs**:
-   - Check `docs/03-decisions/` for numbering
-   - Look for related decisions
-
-4. **Generate ADR**:
-   - File: `docs/03-decisions/ADR-###-descriptive-title.md`
-   - Use MADR (Markdown Architecture Decision Records) format
-   - Mark status as "Proposed" unless decision is final
-
-5. **Confirm with user**: Show the ADR and ask for corrections
-
-## ADR Format (MADR)
-
-```markdown
-# [ADR-###] Title
-
-**Date**: YYYY-MM-DD
-**Status**: Proposed | Accepted | Deprecated | Superseded
-**Deciders**: Names of people involved
-**Tags**: architecture, database, api, etc.
-
-## Context and Problem Statement
-
-[Describe the context and problem. What are we trying to solve? Why necessary?]
-
-## Decision Drivers
-
-- [Driver 1: e.g., Performance requirements]
-- [Driver 2: e.g., Team expertise]
-- [Driver 3: e.g., Cost constraints]
-
-## Considered Options
-
-- [Option 1]
-- [Option 2]
-- [Option 3]
-
-## Decision Outcome
-
-**Chosen option**: [Option X]
-
-**Justification**: [Why chosen? What makes it best fit?]
-
-### Positive Consequences
-
-- [Good outcome 1]
-- [Good outcome 2]
-
-### Negative Consequences
-
-- [Bad outcome 1]
-- [Bad outcome 2 - with mitigation if possible]
-
-## Pros and Cons of the Options
-
-### [Option 1]
-
-**Pros**:
-- [Pro 1]
-- [Pro 2]
-
-**Cons**:
-- [Con 1]
-- [Con 2]
-
-## Links
-
-- [Related ADRs]
-- [Relevant documentation]
-- [External resources]
-
-## Notes
-
-- [Additional information]
-- [Implementation notes]
-```
-
-## ADR Statuses
-
-- **Proposed**: Under consideration, not yet decided
-- **Accepted**: Decision made and approved
-- **Deprecated**: No longer relevant (but kept for history)
-- **Superseded**: Replaced by a newer decision (link to new ADR)
-
-## Quality Checklist
-
-Before creating ADR:
-- [ ] Problem statement is clear and specific
-- [ ] At least 2 options were considered
-- [ ] Each option has pros and cons listed
-- [ ] Decision drivers are explicitly stated
-- [ ] Chosen option has clear justification
-- [ ] Consequences (both positive and negative) documented
-- [ ] File name follows pattern: ADR-###-descriptive-title.md
-- [ ] Status is appropriate (Proposed/Accepted)
-
-## Integration
-
-- **agileflow-story-writer**: ADRs inform technical notes in stories
-- **agileflow-tech-debt**: Negative consequences become tech debt items
-- **agileflow-changelog**: Major decisions appear in changelog
-
-## Notes
-
-- Capture decisions even if they seem small - they provide context later
-- Be honest about negative consequences - helps with future decisions
-- Include who made the decision (deciders) - accountability matters
-- Date decisions - context changes over time
-- Keep ADRs focused - one decision per ADR
-- ADRs are immutable once accepted - create new ADR if superseding

package/src/core/skills/agileflow-adr/examples/database-choice-example.md

@@ -1,122 +0,0 @@
-# [ADR-012] Use PostgreSQL for Primary Database
-
-**Date**: 2025-01-15
-**Status**: Accepted
-**Deciders**: Tech Lead, Backend Team, DevOps
-**Tags**: database, architecture, backend
-
-## Context and Problem Statement
-
-Our application needs a primary database to store user data, transactions, and analytics. We need to choose a database that supports complex queries, transactions, and can scale with our growing user base (currently 10K users, expecting 100K+ within 6 months).
-
-## Decision Drivers
-
-- **Strong ACID compliance** - Financial transactions require data integrity
-- **Complex query support** - Analytics require joins and aggregations
-- **Team expertise** - Team has SQL experience but limited NoSQL experience
-- **Cost** - Must fit within infrastructure budget (~$200/month)
-- **Scalability** - Need to handle 10x growth over 6 months
-- **Operational overhead** - Limited DevOps resources for maintenance
-
-## Considered Options
-
-- PostgreSQL
-- MongoDB
-- MySQL
-
-## Decision Outcome
-
-**Chosen option**: PostgreSQL
-
-**Justification**: PostgreSQL offers the best balance of ACID compliance, query flexibility, and team expertise. While MongoDB could handle our document-like user profiles well, the financial transaction requirements demand strong consistency guarantees. PostgreSQL's JSON support gives us flexibility for semi-structured data without sacrificing transactional integrity.
-
-### Positive Consequences
-
-- Strong ACID guarantees protect financial data
-- Team can leverage existing SQL knowledge immediately
-- Rich ecosystem of tools (pg Admin, extensions, ORMs)
-- JSON/JSONB support provides flexibility for evolving schemas
-- Excellent performance for our expected load (<1M rows initially)
-- Free and open source - no licensing costs
-- Proven scalability path (read replicas, partitioning, Citus extension)
-
-### Negative Consequences
-
-- Vertical scaling limits eventually require sharding strategy
-- Less flexible schema changes compared to schema-less databases
-- Requires careful query optimization for complex analytics
-- Team needs to learn PostgreSQL-specific features (JSONB, window functions)
-
-## Pros and Cons of the Options
-
-### PostgreSQL
-
-**Pros**:
-- ✅ Strong ACID compliance with serializable isolation
-- ✅ Excellent support for complex queries (JOINs, CTEs, window functions)
-- ✅ JSONB for flexible semi-structured data
-- ✅ Rich extension ecosystem (PostGIS, pg_trgm, etc.)
-- ✅ Free and open source
-- ✅ Battle-tested at scale (Instagram, Spotify, GitHub use it)
-- ✅ Team has SQL experience
-
-**Cons**:
-- ❌ Vertical scaling limits (~10M rows before needing partitioning)
-- ❌ Schema migrations require downtime for large tables
-- ❌ Write performance lower than NoSQL for high-throughput scenarios
-- ❌ Replication complexity for multi-region deployment
-
-### MongoDB
-
-**Pros**:
-- ✅ Flexible schema for rapidly evolving data models
-- ✅ Horizontal scaling built-in (sharding)
-- ✅ Fast writes for high-throughput scenarios
-- ✅ Good for document-oriented data (user profiles, products)
-- ✅ Built-in replication and failover
-
-**Cons**:
-- ❌ Weaker consistency guarantees (eventual consistency by default)
-- ❌ Limited transaction support (only multi-document ACID since v4.0)
-- ❌ Team has no MongoDB experience (3-6 month learning curve)
-- ❌ More expensive managed hosting (~$400/month vs $200 for PostgreSQL)
-- ❌ Complex queries less efficient (no JOINs)
-- ❌ Analytics require aggregation pipeline (steep learning curve)
-
-### MySQL
-
-**Pros**:
-- ✅ Strong ACID compliance
-- ✅ Widely used and well-documented
-- ✅ Team has SQL experience
-- ✅ Good performance for read-heavy workloads
-- ✅ Free and open source
-
-**Cons**:
-- ❌ Weaker JSON support compared to PostgreSQL
-- ❌ Less feature-rich (no CTEs until v8.0, weaker window functions)
-- ❌ Replication can be complex (binlog issues)
-- ❌ Extension ecosystem less rich than PostgreSQL
-- ❌ Oracle ownership concerns (licensing changes)
-
-## Links
-
-- [PostgreSQL JSON Support](https://www.postgresql.org/docs/current/datatype-json.html)
-- [Scalability Guide](docs/architecture/postgres-scaling.md)
-- [Database Schema Design](docs/architecture/schema-design.md)
-- Related: [ADR-013: Use Prisma ORM](./ADR-013-use-prisma-orm.md)
-
-## Notes
-
-- **Migration path**: If we hit PostgreSQL scaling limits (>10M users), we'll evaluate:
-  1. Citus extension for horizontal scaling
-  2. Read replicas for read-heavy queries
-  3. Vertical scaling to larger instances
-
-- **Review date**: 2025-06-15 (6 months) - Assess if decision still holds with actual usage data
-
-- **Monitoring**: Set up alerts for:
-  - Query performance degradation
-  - Table size growth
-  - Replication lag
-  - Connection pool exhaustion

package/src/core/skills/agileflow-adr/templates/adr-template.md

@@ -1,69 +0,0 @@
-# [ADR-###] {Title}
-
-**Date**: {YYYY-MM-DD}
-**Status**: {Proposed | Accepted | Deprecated | Superseded}
-**Deciders**: {Names}
-**Tags**: {tag1, tag2}
-
-## Context and Problem Statement
-
-{Describe the context and problem}
-
-## Decision Drivers
-
-- {Driver 1}
-- {Driver 2}
-- {Driver 3}
-
-## Considered Options
-
-- {Option 1}
-- {Option 2}
-- {Option 3}
-
-## Decision Outcome
-
-**Chosen option**: {Option X}
-
-**Justification**: {Why this option}
-
-### Positive Consequences
-
-- {Good outcome 1}
-- {Good outcome 2}
-
-### Negative Consequences
-
-- {Bad outcome 1}
-- {Bad outcome 2}
-
-## Pros and Cons of the Options
-
-### {Option 1}
-
-**Pros**:
-- {Pro 1}
-- {Pro 2}
-
-**Cons**:
-- {Con 1}
-- {Con 2}
-
-### {Option 2}
-
-**Pros**:
-- {Pro 1}
-- {Pro 2}
-
-**Cons**:
-- {Con 1}
-- {Con 2}
-
-## Links
-
-- {Related ADRs}
-- {Documentation}
-
-## Notes
-
-- {Additional information}

package/src/core/skills/agileflow-commit-messages/SKILL.md

@@ -1,130 +0,0 @@
----
-name: agileflow-commit-messages
-description: Formats git commit messages following Conventional Commits and respects user's attribution preferences from CLAUDE.md
----
-
-# Conventional Commits Skill
-
-Automatically formats git commit messages following the Conventional Commits specification while respecting the user's attribution policy defined in CLAUDE.md.
-
-## When to Use
-
-This skill activates when:
-- Creating or staging git commits
-- Discussing code changes that need committing
-- Keywords: "commit", "git commit", "conventional commit", "commit message"
-
-## What This Does
-
-1. Checks CLAUDE.md for attribution policy (respects user preferences)
-2. Analyzes staged changes to determine commit type and scope
-3. Formats message using Conventional Commits format
-4. Shows message to user for approval before executing
-
-## Instructions
-
-1. **Check attribution policy**:
-   - Read CLAUDE.md for "Git Commit Attribution Policy"
-   - If "DO NOT ADD AI ATTRIBUTION" found → skip footer
-   - Otherwise → prepare attribution footer
-
-2. **Analyze changes**:
-   - Run `git diff --cached --stat` to see staged files
-   - Determine primary change type (feat, fix, refactor, etc.)
-   - Identify affected scope (api, ui, auth, db, config, etc.)
-
-3. **Format message**:
-   ```
-   <type>(<scope>): <subject>
-
-   <body>
-
-   <footer>
-   ```
-
-4. **Show for approval**: Display formatted message (diff-first pattern)
-
-5. **Execute after confirmation**: Run git commit with user's YES
-
-## Conventional Commits Format
-
-**Types**: feat, fix, docs, style, refactor, perf, test, chore, ci, revert
-
-**Scope (optional)**: (api), (ui), (auth), (db), (config), etc.
-
-**Subject rules**:
-- Imperative mood: "add feature" not "added feature"
-- Lowercase, no period, max 50 characters
-
-**Body (optional)**:
-- Explain WHAT and WHY (not HOW)
-- Wrap at 72 characters per line
-
-**Footer (optional)**:
-- Issue references: `Closes #123`
-- Breaking changes: `BREAKING CHANGE: description`
-- Attribution: Add if CLAUDE.md allows
-
-## Output Examples
-
-**WITH attribution** (default):
-```
-feat(auth): add two-factor authentication
-
-Implemented TOTP-based 2FA with QR code generation
-for enhanced user account security.
-
-Closes #234
-
-🤖 Generated with [Claude Code](https://claude.com/claude-code)
-
-Co-Authored-By: Claude <noreply@anthropic.com>
-```
-
-**WITHOUT attribution** (if CLAUDE.md specifies):
-```
-feat(auth): add two-factor authentication
-
-Implemented TOTP-based 2FA with QR code generation
-for enhanced user account security.
-
-Closes #234
-```
-
-**Breaking changes**:
-```
-feat(api)!: change authentication endpoint structure
-
-BREAKING CHANGE: The /auth/login endpoint now returns
-a different response format.
-
-Old: { token: "..." }
-New: { accessToken: "...", refreshToken: "...", expiresIn: 3600 }
-
-Closes #456
-```
-
-## Quality Checklist
-
-Before suggesting commit message:
-- [ ] Type is appropriate (feat/fix/refactor/docs/chore)
-- [ ] Subject uses imperative mood
-- [ ] Subject is lowercase, <50 chars, no period
-- [ ] Body explains WHY, wrapped at 72 chars
-- [ ] **Attribution policy checked in CLAUDE.md** (CRITICAL)
-- [ ] No secrets in staged files (.env, tokens, credentials)
-- [ ] Breaking changes marked with `!` and `BREAKING CHANGE:` footer
-
-## Integration
-
-- **agileflow-changelog**: Commit messages inform changelog entries
-- **agileflow-story-writer**: Reference story IDs in commits (Closes STORY-042)
-- **agileflow-adr**: Link ADRs in footer (Refs: ADR-0005)
-
-## Notes
-
-- ALWAYS check CLAUDE.md first for attribution preferences
-- For large commits, suggest breaking into smaller logical commits
-- Keep line lengths: subject <50 chars, body <72 chars
-- Check for secrets before committing (.env, credentials.json, API keys)
-- Security check: Warn user if sensitive files are staged

package/src/core/skills/agileflow-commit-messages/reference/bad-examples.md

@@ -1,168 +0,0 @@
-# Bad Commit Message Examples (and How to Fix Them)
-
-## ❌ Too Vague
-
-```
-fix: fix bug
-```
-
-**Problem**: Doesn't explain what bug was fixed
-**Better**:
-```
-fix(auth): prevent session timeout during active use
-
-Fixed bug where user sessions expired after 30 minutes
-even during active usage. Now sessions extend while user
-is interacting with the application.
-
-Fixes #456
-```
-
-## ❌ Wrong Tense
-
-```
-feat: added dark mode
-```
-
-**Problem**: Should be imperative mood ("add" not "added")
-**Better**:
-```
-feat(ui): add dark mode toggle
-
-Implemented dark mode with localStorage persistence
-and system preference detection.
-
-Closes #789
-```
-
-## ❌ Subject Too Long
-
-```
-feat: add a new user profile editing feature that allows users to update their name, email, and profile picture
-```
-
-**Problem**: Subject exceeds 50 characters, should be concise
-**Better**:
-```
-feat(profile): add user profile editing
-
-Users can now update their name, email, and profile
-picture from the settings page. Changes are validated
-server-side and saved to the database.
-
-Closes #123
-```
-
-## ❌ No Type
-
-```
-update README
-```
-
-**Problem**: Missing type prefix
-**Better**:
-```
-docs(readme): add API authentication examples
-
-Added code examples showing how to authenticate API
-requests using JWT tokens.
-```
-
-## ❌ Multiple Unrelated Changes
-
-```
-feat: add login and fix cart bug and update dependencies
-```
-
-**Problem**: Should be 3 separate commits
-**Better**: Split into:
-```
-feat(auth): add user login functionality
-```
-```
-fix(cart): resolve item duplication issue
-```
-```
-chore(deps): update npm packages to latest versions
-```
-
-## ❌ Description of HOW Instead of WHY
-
-```
-fix: changed if statement to switch statement
-```
-
-**Problem**: Describes implementation detail, not the reason
-**Better**:
-```
-refactor(validation): simplify input validation logic
-
-Replaced nested if statements with switch statement
-for better readability and easier maintenance. No
-functional changes.
-```
-
-## ❌ Capitalized Subject
-
-```
-feat: Add Dark Mode Support
-```
-
-**Problem**: Subject should be lowercase
-**Better**:
-```
-feat(ui): add dark mode support
-```
-
-## ❌ Period at End of Subject
-
-```
-fix: resolve login timeout issue.
-```
-
-**Problem**: Subject shouldn't end with period
-**Better**:
-```
-fix(auth): resolve login timeout issue
-
-Increased session timeout from 15 to 30 minutes to
-prevent premature logouts during form filling.
-
-Fixes #567
-```
-
-## ❌ No Context
-
-```
-fix: it works now
-```
-
-**Problem**: Completely uninformative
-**Better**:
-```
-fix(payment): resolve Stripe webhook signature validation
-
-Fixed HMAC signature verification by using raw request
-body instead of parsed JSON. Webhooks now process correctly.
-
-Fixes #890
-```
-
-## ❌ Missing Issue Reference
-
-```
-feat: add two-factor authentication
-
-Implemented TOTP-based 2FA with QR code generation.
-```
-
-**Problem**: Should reference the issue/story
-**Better**:
-```
-feat(auth): add two-factor authentication
-
-Implemented TOTP-based 2FA with QR code generation
-for enhanced account security.
-
-Closes #234, STORY-042
-```