From afyapowers
Use after any implementation is finished to automatically generate or update feature documentation in docs/afyapowers/ — analyzes changes, matches to existing docs by domain area, and maintains living documentation with changelog
npx claudepluginhub iclinic/devex-marketplace --plugin afyapowersThis skill uses the workspace's default tool permissions.
Automatically generate or update living feature documentation after implementation work completes.
Provides Ktor server patterns for routing DSL, plugins (auth, CORS, serialization), Koin DI, WebSockets, services, and testApplication testing.
Conducts multi-source web research with firecrawl and exa MCPs: searches, scrapes pages, synthesizes cited reports. For deep dives, competitive analysis, tech evaluations, or due diligence.
Provides demand forecasting, safety stock optimization, replenishment planning, and promotional lift estimation for multi-location retailers managing 300-800 SKUs.
Automatically generate or update living feature documentation after implementation work completes.
/afyapowers:* workflow. The agent invokes this skill when it recognizes implementation is complete.Determine what was changed by running a git diff:
# Detect default branch
DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo "main")
CURRENT_BRANCH=$(git branch --show-current)
if [ "$CURRENT_BRANCH" = "$DEFAULT_BRANCH" ]; then
# On default branch — diff the last commit
git diff HEAD~1
else
# On feature branch — diff against default branch
git diff "$DEFAULT_BRANCH"..."$CURRENT_BRANCH"
fi
If the diff is empty (no changes), skip documentation entirely. Inform the user: "No changes detected — skipping documentation update." Stop here.
docs/afyapowers/ exists in the project root. If not, create it.docs/afyapowers/ is not gitignored. Check the project's .gitignore — if it contains a pattern that would exclude docs/afyapowers/, add a negation pattern:!docs/afyapowers/
This ensures documentation files can be committed to the repository.
Read all docs/afyapowers/*.md files. For each file, extract:
# Title heading)If no docs exist yet, skip to Step 5 (create new doc).
Analyze the git diff and compare it to the existing documentation:
This is a judgment call — use the diff content and existing docs to make the best match. Do not use keyword heuristics; reason about the semantic domain of the changes.
templates/feature-doc.md as the starting structure.session-hooks.md, authentication.md, auto-documentation.md).Commit the documentation changes:
git add docs/afyapowers/
git commit -m "docs: update docs/afyapowers/<feature-name>.md"
If multiple docs were updated, adjust the commit message accordingly:
git commit -m "docs: update feature documentation"
Each docs/afyapowers/FEATURE-NAME.md follows this structure:
# Feature Name
## Overview
Brief description of what this feature does and why it exists.
## Business Rules
- Rule 1: description
- Rule 2: description
## Usage
How to use the feature — configuration, API, commands, etc.
## Technical Details
### Architecture
Key components, how they connect, where they live.
### Key Files
- `path/to/file.ts` — purpose
### Data Flow
How data moves through the feature.
## Changelog
### 2026-03-13
- **What:** Detailed description of the changes made
- **Files:** `src/session/config.ts`, `src/session/middleware.ts`
Each entry under a date heading contains:
When generating documentation, use these sources in priority order:
.afyapowers/features/<feature>/artifacts/ exists, read design.md, plan.md, and review.md for rich context about requirements, architecture, and decisions. These are optional but produce significantly better docs.