npm - cfsa-antigravity - Versions diffs - 1.0.0 - Mend

cfsa-antigravity 1.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (378) hide show

package/template/.agent/skills/git-workflow/SKILL.md ADDED Viewed

@@ -0,0 +1,420 @@
+---
+name: git-workflow
+description: Essential Git patterns for effective version control, eliminating redundant Git guidance per agent.
+license: Apache-2.0
+compatibility: claude-code
+metadata:
+  updated_at: 2025-10-30T17:00:00Z
+tags: [git, version-control, workflow, best-practices]
+progressive_disclosure:
+  entry_point:
+    summary: "Essential Git patterns for effective version control, eliminating redundant Git guidance per agent."
+    when_to_use: "When working with version control, branches, or pull requests."
+    quick_start: "1. Review the core concepts below. 2. Apply patterns to your use case. 3. Follow best practices for implementation."
+---
+# Git Workflow
+Essential Git patterns for effective version control. Eliminates ~120-150 lines of redundant Git guidance per agent.
+## Commit Best Practices
+### Conventional Commits Format
+```
+<type>(<scope>): <subject>
+<body>
+<footer>
+```
+**Types:**
+- `feat`: New feature
+- `fix`: Bug fix
+- `docs`: Documentation only
+- `refactor`: Code change that neither fixes bug nor adds feature
+- `perf`: Performance improvement
+- `test`: Adding or updating tests
+- `chore`: Build process, dependencies, tooling
+**Examples:**
+```bash
+feat(auth): add OAuth2 authentication
+Implements OAuth2 flow using Google provider.
+Includes token refresh and validation.
+Closes #123
+fix(api): handle null response in user endpoint
+Previously crashed when user not found.
+Now returns 404 with error message.
+perf(db): optimize user query with index
+Reduces query time from 500ms to 50ms.
+```
+### Atomic Commits
+```bash
+# Good: Each commit does one thing
+git commit -m "feat: add user authentication"
+git commit -m "test: add auth tests"
+git commit -m "docs: update API docs for auth"
+# Bad: Multiple unrelated changes
+git commit -m "add auth, fix bugs, update docs"
+```
+## Branching Strategy
+### Git Flow (Feature Branches)
+```bash
+# Create feature branch from main
+git checkout main
+git pull origin main
+git checkout -b feature/user-authentication
+# Work on feature with regular commits
+git add src/auth.py
+git commit -m "feat(auth): implement login endpoint"
+# Keep branch updated with main
+git checkout main
+git pull origin main
+git checkout feature/user-authentication
+git rebase main  # Or: git merge main
+# Push and create PR
+git push -u origin feature/user-authentication
+```
+### Trunk-Based Development
+```bash
+# Work directly on main with short-lived branches
+git checkout main
+git pull origin main
+git checkout -b fix/null-pointer
+# Make small change
+git commit -m "fix: handle null in user query"
+git push origin fix/null-pointer
+# Merge immediately via PR
+```
+## Common Workflows
+### Updating Branch with Latest Changes
+```bash
+# Option 1: Rebase (cleaner history)
+git checkout feature-branch
+git fetch origin
+git rebase origin/main
+# Resolve conflicts if any
+git add resolved_file.py
+git rebase --continue
+# Option 2: Merge (preserves history)
+git checkout feature-branch
+git merge origin/main
+```
+### Undoing Changes
+```bash
+# Undo last commit (keep changes)
+git reset --soft HEAD~1
+# Undo last commit (discard changes)
+git reset --hard HEAD~1
+# Undo changes to specific file
+git checkout -- file.py
+# Revert a commit (creates new commit)
+git revert abc123
+# Amend last commit
+git add forgotten_file.py
+git commit --amend --no-edit
+```
+### Stashing Work
+```bash
+# Save current work temporarily
+git stash
+# List stashes
+git stash list
+# Apply most recent stash
+git stash pop
+# Apply specific stash
+git stash apply stash@{0}
+# Create named stash
+git stash save "WIP: authentication feature"
+```
+### Cherry-Picking Commits
+```bash
+# Apply specific commit from another branch
+git cherry-pick abc123
+# Cherry-pick multiple commits
+git cherry-pick abc123 def456
+# Cherry-pick without committing
+git cherry-pick -n abc123
+```
+## Resolving Conflicts
+```bash
+# When conflicts occur during merge/rebase
+# 1. Check conflicted files
+git status
+# 2. Edit files to resolve conflicts
+# Look for conflict markers:
+<<<<<<< HEAD
+Your changes
+=======
+Their changes
+>>>>>>> branch-name
+# 3. Mark as resolved
+git add resolved_file.py
+# 4. Continue operation
+git rebase --continue  # or git merge --continue
+```
+## Viewing History
+```bash
+# Compact log
+git log --oneline -10
+# Graphical log
+git log --graph --oneline --all
+# Commits by author
+git log --author="John Doe"
+# Commits affecting specific file
+git log -- path/to/file.py
+# See changes in commit
+git show abc123
+# Compare branches
+git diff main..feature-branch
+```
+## Branch Management
+```bash
+# List branches
+git branch -a  # All branches (local + remote)
+# Delete local branch
+git branch -d feature-branch  # Safe delete (merged only)
+git branch -D feature-branch  # Force delete
+# Delete remote branch
+git push origin --delete feature-branch
+# Rename branch
+git branch -m old-name new-name
+# Track remote branch
+git checkout --track origin/feature-branch
+```
+## Tags
+```bash
+# Create lightweight tag
+git tag v1.0.0
+# Create annotated tag (recommended)
+git tag -a v1.0.0 -m "Release version 1.0.0"
+# Push tags to remote
+git push origin v1.0.0
+git push origin --tags  # Push all tags
+# Checkout tag
+git checkout v1.0.0
+# Delete tag
+git tag -d v1.0.0
+git push origin --delete v1.0.0
+```
+## Advanced Operations
+### Interactive Rebase
+```bash
+# Edit last 3 commits
+git rebase -i HEAD~3
+# Options in editor:
+# pick = use commit
+# reword = change commit message
+# edit = stop to amend commit
+# squash = combine with previous commit
+# fixup = like squash but discard message
+# drop = remove commit
+```
+### Bisect (Find Bug Introduction)
+```bash
+# Start bisect
+git bisect start
+git bisect bad  # Current version has bug
+git bisect good v1.0.0  # This version was good
+# Git checks out middle commit
+# Test if bug exists
+git bisect bad  # if bug exists
+git bisect good  # if bug doesn't exist
+# Git narrows down until finding first bad commit
+git bisect reset  # Return to original branch
+```
+### Blame (Find Who Changed Line)
+```bash
+# See who last modified each line
+git blame file.py
+# Ignore whitespace changes
+git blame -w file.py
+# Show specific line range
+git blame -L 10,20 file.py
+```
+## Git Hooks
+```bash
+# Pre-commit hook (runs before commit)
+# .git/hooks/pre-commit
+#!/bin/bash
+npm run lint
+npm test
+# Pre-push hook (runs before push)
+# .git/hooks/pre-push
+#!/bin/bash
+npm run test:integration
+```
+## Best Practices
+### ✅ DO
+- Commit frequently with atomic changes
+- Write clear, descriptive commit messages
+- Pull before push to avoid conflicts
+- Review changes before committing (`git diff --staged`)
+- Use branches for features and fixes
+- Keep commits small and focused
+### ❌ DON'T
+- Commit sensitive data (use `.gitignore`)
+- Commit generated files (build artifacts, `node_modules`)
+- Force push to shared branches (`git push --force`)
+- Commit work-in-progress to main
+- Include multiple unrelated changes in one commit
+- Rewrite public history
+## .gitignore Patterns
+```gitignore
+# Dependencies
+node_modules/
+venv/
+__pycache__/
+# Build outputs
+dist/
+build/
+*.pyc
+*.o
+*.exe
+# IDE
+.vscode/
+.idea/
+*.swp
+# Secrets
+.env
+*.key
+*.pem
+secrets.yml
+# OS
+.DS_Store
+Thumbs.db
+# Logs
+*.log
+logs/
+```
+## Quick Command Reference
+```bash
+# Status and diff
+git status
+git diff
+git diff --staged
+# Commit
+git add .
+git commit -m "message"
+git push
+# Branch
+git branch
+git checkout -b branch-name
+git merge branch-name
+# Update
+git pull
+git fetch
+# Undo
+git reset HEAD~1
+git checkout -- file
+git revert commit-hash
+# History
+git log
+git log --oneline
+git show commit-hash
+```
+## Remember
+- **Commit often** - Small commits are easier to review and revert
+- **Descriptive messages** - Future you will thank present you
+- **Pull before push** - Stay synchronized with team
+- **Use branches** - Keep main stable
+- **Review before commit** - Check what is being committed

package/template/.agent/skills/idea-extraction/SKILL.md ADDED Viewed

@@ -0,0 +1,271 @@
+---
+name: idea-extraction
+description: "Exhaustive idea extraction through input-adaptive interviewing. Use during /ideate to transform raw ideas — whether richly documented, lightly sketched, or entirely in the user's head — into comprehensive vision material. This is NOT a quick Q&A — it's a deep, collaborative exploration that refuses to stop until every domain is explored."
+---
+# Idea Extraction — Exhaustion Engine
+## Philosophy
+> This pipeline does not build MVPs. It does not produce shallow specs. It does not
+> create technical debt by rushing past the ideation phase. The ideation phase is where
+> the entire downstream pipeline gets its DNA — if the vision is shallow, every spec,
+> every architecture decision, every line of code downstream will be shallow too.
+This skill exists because the ideation phase is the **front door** of a production-grade
+pipeline. The brainstorming skill is deliberately lightweight — it's a modifier skill for
+quick collaborative decisions. This skill is the opposite: it's an **exhaustion engine**
+designed to extract every ounce of product vision from the user, whether that vision is
+already documented, partially formed, or entirely in their head.
+Your job is not to collect answers. Your job is to **generate new thinking** in the user
+by asking questions they haven't considered, exploring edges they haven't mapped, and
+helping them make decisions they haven't faced yet.
+---
+## Input-Adaptive Modes
+Before starting, classify what the user has provided and select the right mode.
+### Extraction Mode — Rich Input
+**Trigger:** User provides substantial existing material (>5KB, detailed docs, chat logs,
+design conversations, competitor analysis, previous specs).
+**The job:** Don't lose information. The user has already done deep thinking — your job is
+to organize it, validate it, and fill gaps.
+**Process:**
+1. Read/ingest every document provided
+2. Enumerate what you found, organized by domain (not by source document)
+3. Present the organized inventory back to the user: "Here's what I extracted, organized by domain. Is anything missing or wrong?"
+4. Identify gaps — domains or sub-topics not covered by the existing material
+5. For each gap, switch to Interview Mode for that topic
+6. Validate completeness against the domain coverage map
+**Anti-patterns:**
+- ❌ Summarizing 738KB into 70 lines (lossy compression)
+- ❌ Ignoring details because they don't fit the template
+- ❌ Re-asking questions the material already answers
+- ✅ Preserving depth, organizing structure, filling gaps
+### Expansion Mode — Thin Input
+**Trigger:** User provides brief notes, a rough sketch, a short PRD (<5KB, structured but shallow).
+**The job:** Take what's there and systematically deepen it. Every bullet point in their
+input should spawn 3-5 follow-up questions that drive toward implementation depth.
+**Process:**
+1. Read the input and understand its structure
+2. For each section, identify the depth level (surface → detailed → implementation-ready)
+3. Start with the shallowest sections first
+4. For each shallow section, ask targeted deepening questions
+5. Build out the domain coverage map as you go
+6. Don't stop until every section reaches implementation depth
+**Deepening questions by section type:**
+- **Feature mentioned without detail:** "You listed [feature]. Help me understand: What does the user see? What happens when they interact with it? What happens when it fails? What data does it need?"
+- **User type without specifics:** "You mentioned [user type]. What's their primary workflow? What are they trying to accomplish? What frustrates them about existing solutions? What would make them switch?"
+- **Constraint without numbers:** "You noted [constraint]. Can we put a number on that? For latency — what's the threshold where users notice? For budget — what's the monthly ceiling?"
+### Interview Mode — No Input / One-Liner
+**Trigger:** User has no file input. They describe the idea verbally or provide a one-liner
+like "I want to build a trading app."
+**The job:** Be the relentless interviewer. Extract everything from the user's head through
+persistent, deep questioning. No topic is "done" until the user explicitly says "I don't
+know" or "I haven't decided" — and even then, help them decide.
+**Process:**
+1. Start with the highest-level question: "In one sentence, what problem does this solve and for whom?"
+2. From that sentence, identify the key nouns — these become your initial domains
+3. For each domain, drill systematically (see Domain Exhaustion Protocol below)
+4. Maintain and share the domain coverage map
+5. Use the decision classification rule to route questions appropriately
+6. Don't stop until the coverage map shows ≥80% of identified domains at ≥3 levels deep
+**Interview techniques:**
+- **Follow the thread:** When a user mentions a concept, drill into it before moving on. Don't breadth-first hop between topics.
+- **Challenge weak answers:** "You mentioned risk management — can you tell me more? For example, what happens when a user hits their position limit? What's the escalation path?"
+- **Generate new thinking:** "You've described [concept A] and [concept B] — what happens when they interact? If A triggers while B is active, what should the system do?"
+- **Make them think about failures:** "What's the worst thing a user could do with [feature]? How should the system prevent or recover from that?"
+- **Help them decide:** When the user says "I'm not sure," don't log it as an open question. Present 2-3 options with trade-offs: "Most platforms handle this one of three ways: [A], [B], or [C]. A is simpler but less flexible. C is powerful but complex to build. B is the middle ground. Which resonates?"
+---
+## Expansion Mode Awareness
+Before beginning any drilling, read the current expansion mode from `ideation.md`. The mode overrides the default depth-first behavior:
+| Mode | Drilling Strategy |
+|---|---|
+| Full | Breadth-first during horizontal sweep; depth-first during vertical drilling; interaction-first during synthesis |
+| Vertical | Depth-first — finish one domain before moving to the next |
+| Horizontal | Breadth-first — map all domains before deepening any |
+| Cross-cutting | Interaction-first — focus on connection points, not individual domain depth |
+| Combination | User-directed — follow the user's specified sequence of modes in order |
+| As-is | No active drilling — scan only |
+### Cross-cut Watch Protocol
+Cross-cut detection is always-on regardless of mode. During all active drilling, ask these questions:
+- After each sub-feature: "Does this behavior depend on or affect any other domain?"
+- After each edge case: "Which other parts of the system need to know about this failure mode?"
+- After each state transition: "Does this state change trigger anything in another domain?"
+When a cross-cut is identified, immediately log it to `## Cross-cutting Candidates` in `ideation.md`:
+`[Domain A] × [Domain B]: [what the connection is]` — status: pending
+Do not stop to explore the cross-cut immediately — flag and continue the current drill. The synthesis pass will address all candidates.
+### Cross-cut Candidate Format
+After synthesis, annotate each candidate with its outcome:
+- `✅ confirmed → see [Interaction Name]`
+- `❌ rejected: [reason]`
+Never clear the candidates section — it is the audit trail.
+---
+## Domain Exhaustion Protocol
+> **Mode-aware**: This protocol operates differently depending on the active expansion mode. Read the Expansion Mode Awareness section above before applying this protocol. In Full Mode, apply breadth-first during the horizontal sweep and depth-first during vertical drilling. In As-is Mode, skip active drilling entirely.
+This is the core mechanism. For every domain identified, drill systematically using these
+questions. **Never accept a bucket label as a feature.** "Risk management" is a category,
+not a feature — drill until you have specific, testable behaviors.
+### For Every Entity
+- What are its attributes/fields?
+- What are its possible states?
+- What transitions between states? What triggers each transition?
+- What's the full lifecycle (creation → active use → archival/deletion)?
+- Who can create, read, update, delete it?
+- What happens when it's referenced by other entities and gets deleted?
+### For Every Feature
+- What does the user see when they first encounter this feature?
+- What's the happy path interaction flow (step by step)?
+- What happens when it fails? What error does the user see?
+- What happens on partial failure (e.g., network drops mid-operation)?
+- What permissions are required? What happens without them?
+- Does it have different states (loading, empty, populated, error)?
+- How does it interact with other features?
+- What edge cases exist? (concurrent edits, duplicate submissions, boundary values)
+### For Every User Type
+- What's their primary workflow through the product?
+- What's the worst thing they could intentionally do? How is it prevented?
+- What's the worst thing they could accidentally do? How is it recovered?
+- What do they see that other user types don't?
+- What can they do that other user types can't?
+- What's their tolerance for complexity? (progressive disclosure implications)
+### For Every Integration / External System
+- What happens when it's unavailable? (retry? fallback? degrade gracefully?)
+- What's the expected latency? What if it's 10x slower than expected?
+- What data format does it use? How does the product transform it?
+- What rate limits exist? How does the product handle hitting them?
+- What happens when the external system changes its API?
+---
+## Domain Coverage Map
+Throughout the conversation, maintain and periodically share a coverage map with the user.
+**Format:**
+```
+Domain Coverage Map — [Project Name]
+═══════════════════════════════════════════
+[████████████ ] Strategy Lifecycle (85%) — 12 sub-topics explored
+[████████░░░░ ] Risk Management (60%) — 7 sub-topics explored
+[████░░░░░░░░ ] Market Data Pipeline (30%) — 3 sub-topics explored
+[░░░░░░░░░░░░ ] AI/ML Integration (5%) — 1 sub-topic mentioned
+[████████████ ] User Authentication (90%) — 10 sub-topics explored
+...
+Overall: 54% complete — 8 domains identified, 3 deeply explored
+Next suggested domain: Risk Management (currently at 60%, high importance)
+```
+**Rules:**
+- Share the map after every 5-6 questions, or whenever switching domains
+- Use it to guide the conversation: "We've covered Strategy deeply. Risk Management is important and only at 60%. Want to dig into that next?"
+- Don't compile the vision document until overall coverage is ≥80%
+- When the user says "I think that's everything," check the map. If domains are under-explored, point it out: "We're at 65% overall. [Domain X] and [Domain Y] are still shallow — should we explore them, or are they intentionally minimal?"
+---
+## Decision Routing During Extraction
+When a decision point arises, classify it using the decision classification rule:
+| Decision Type | During Ideation | Example |
+|---|---|---|
+| **Product** | Ask the user. It's their product. | "Should free users be able to...?" |
+| **Architecture** | Note it for `/create-prd`. Don't burden the user. | "Should we use SQL or NoSQL?" |
+| **Implementation** | Note it for later. Don't even mention it. | "How should we name the routes?" |
+**Exception:** If the user brings up an architecture or implementation topic, engage with it.
+Don't refuse to discuss it — just don't initiate it. The user may have strong opinions about
+their tech stack, and those opinions are valuable context.
+---
+## Anti-Rushing Mechanisms
+### Depth Before Breadth
+Finish exploring the current topic completely before moving to the next. If you're
+discussing "user authentication," don't jump to "payment processing" until auth is
+explored to satisfaction. The user can redirect if they want — but you shouldn't hop.
+### No Premature Compilation
+Don't start writing the output document until:
+- At least 80% of identified domains are explored
+- Every Must Have feature has been discussed at level ≥2 (sub-features and failure modes)
+- The user has confirmed the domain coverage map
+### Challenge Weak Answers
+When the user gives a one-sentence answer to a complex question, don't accept it. Probe
+deeper with a concrete follow-up:
+- **Weak:** "Yeah, we need notifications."
+- **Probe:** "What kinds of notifications? Just in-app, or also email and push? What events trigger them? Can users configure which ones they receive? What happens with notification overload?"
+### Summarize and Validate
+After every 5-6 questions, pause and summarize:
+- "Here's what I've captured about [topic] so far: [summary]. Does this cover everything, or is there more?"
+- This prevents drift, catches misunderstandings early, and gives the user a chance to add things they forgot.
+### Progress Transparency
+Don't let the user wonder "how much longer." Be transparent:
+- "We've covered [N] of [M] domains. We're about [X]% through the exploration."
+- "This is a complex project — I want to make sure we don't miss anything that will cause rework later. We've got [domains] left to explore."
+---
+## What This Skill Does NOT Do
+- **Does not make product decisions** — It extracts them from the user
+- **Does not explore architecture** — That's `/create-prd`'s job
+- **Does not replace brainstorming** — Brainstorming is a lightweight modifier skill for quick decisions; this skill is a heavyweight extraction engine for ideation only
+- **Does not produce the vision document** — The ideate workflow compiles the document; this skill drives the conversation that produces the raw material
+- **Does not rush** — The entire downstream pipeline depends on the depth produced here