agileflow 2.61.0 → 2.63.0

package/src/core/skills/agileflow-acceptance-criteria/SKILL.md

@@ -1,156 +0,0 @@
----
-name: agileflow-acceptance-criteria
-description: Generates detailed Given/When/Then acceptance criteria when user describes feature behavior or requirements. Enhances user stories with testable scenarios.
----
-
-# AgileFlow Acceptance Criteria
-
-Automatically generates detailed, testable acceptance criteria in Given/When/Then (Gherkin) format from feature discussions and requirements.
-
-## When to Use
-
-This skill activates when:
-- User describes how a feature should behave
-- Discussing user workflows or interactions
-- Keywords: "acceptance criteria", "test scenarios", "should work like"
-- Creating or reviewing user stories
-- User describes "when user does X, then Y should happen"
-
-## What This Does
-
-1. Extracts feature behavior from user discussions
-2. Identifies different scenarios (happy path, errors, edge cases)
-3. Generates criteria in Given/When/Then format
-4. Ensures criteria are specific, testable, and independent
-5. Enhances story's AC section
-
-## Instructions
-
-1. **Listen for behavior descriptions**: User explains "when X happens, Y should occur"
-
-2. **Extract scenarios**:
-   - Happy path (normal use)
-   - Error cases (what goes wrong)
-   - Edge cases (boundary conditions)
-   - Permission-based scenarios
-
-3. **Generate criteria**:
-   - One AC per distinct scenario
-   - Clear, unambiguous language
-   - Make it testable (observable outcome)
-   - Include edge cases
-
-4. **Add to story**: If working on a story, enhance its AC section
-
-## Given/When/Then Format
-
-```markdown
-### AC#: [Criterion Name]
-**Given** [initial context or precondition]
-**When** [user action or trigger event]
-**Then** [expected outcome or system behavior]
-```
-
-**Given** (Precondition):
-- User's current state, system state, data that exists, permissions/roles
-- Example: "Given I am logged in as an admin"
-
-**When** (Action):
-- What the user does, event that occurs, API call made
-- Example: "When I click the 'Add to Cart' button"
-
-**Then** (Outcome):
-- What the user sees, system state changes, data modifications, error messages
-- Example: "Then the item is added to my cart"
-
-## Common Patterns
-
-**Happy Path**:
-```markdown
-### AC1: Successful Login
-**Given** I am on the login page
-**When** I enter valid credentials and click "Login"
-**Then** I am redirected to my dashboard
-**And** I see a welcome message with my name
-```
-
-**Error Handling**:
-```markdown
-### AC2: Invalid Password
-**Given** I am on the login page
-**When** I enter a valid email but incorrect password
-**Then** I see an error message "Invalid credentials"
-**And** I remain on the login page
-```
-
-**Edge Cases**:
-```markdown
-### AC3: Account Locked After Failed Attempts
-**Given** I have failed to login 4 times
-**When** I attempt to login with incorrect password again
-**Then** my account is locked for 30 minutes
-**And** an email is sent to my registered address
-```
-
-**Permission-Based**:
-```markdown
-### AC4: Admin-Only Feature Access
-**Given** I am logged in as a regular user
-**When** I try to access the admin dashboard
-**Then** I see a 403 Forbidden error
-```
-
-**Form Validation**:
-```markdown
-### AC1: Email Format Validation
-**Given** I am filling out the registration form
-**When** I enter an invalid email format (missing @)
-**Then** I see an error "Please enter a valid email address"
-**And** the submit button remains disabled
-```
-
-## Multiple Conditions
-
-Use **And** for additional conditions:
-```markdown
-**Given** I am logged in
-**And** I have items in my cart
-**When** I click "Checkout"
-**Then** I am redirected to payment page
-**And** I see my cart summary
-```
-
-Use **But** for contrasting outcomes:
-```markdown
-**Given** I am on the search page
-**When** I search for "nonexistent product"
-**Then** I see "No results found" message
-**But** I see suggested categories
-```
-
-## Quality Checklist
-
-Good acceptance criteria are:
-- [ ] **Specific**: Clearly describes one scenario
-- [ ] **Testable**: Can be verified with a test
-- [ ] **Independent**: Doesn't depend on order of execution
-- [ ] **Unambiguous**: Only one interpretation possible
-- [ ] **Complete**: Covers happy path, errors, and edge cases
-- [ ] **User-focused**: Written from user's perspective
-- [ ] **3-7 criteria per story**: Enough coverage, not excessive
-
-## Integration
-
-- **agileflow-story-writer**: Automatically enhances story AC sections
-- **agileflow-sprint-planner**: Helps estimate story complexity from AC count
-- **agileflow-tech-debt**: Identifies missing test coverage from AC
-
-## Notes
-
-- Aim for 3-7 acceptance criteria per story
-- Too few = incomplete requirements
-- Too many = story should be split
-- Cover at least one error case per story
-- Include accessibility criteria when relevant
-- Consider mobile vs desktop differences
-- Think about internationalization if applicable

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