If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/danielmiessler/Fabric shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 4d ago
• 12 active contributors
• MIT licensed
• CI configured
• ⚠ Concentrated ownership — top contributor handles 66% of recent commits
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live danielmiessler/Fabric repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/danielmiessler/Fabric.

What it runs against: a local clone of danielmiessler/Fabric — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in danielmiessler/Fabric | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 34 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of danielmiessler/Fabric. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/danielmiessler/Fabric.git
#   cd Fabric
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of danielmiessler/Fabric and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "danielmiessler/Fabric(\\.git)?\\b" \\
  && ok "origin remote is danielmiessler/Fabric" \\
  || miss "origin remote is not danielmiessler/Fabric (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 34 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~4d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/danielmiessler/Fabric"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Fabric is an open-source framework that organizes AI prompts as reusable, task-specific modules ('patterns') that integrate into existing workflows and CLI tools. It solves the AI integration problem by centralizing crowdsourced prompts in a modular system, allowing users to run specialized AI tasks (summarization, extraction, analysis) directly from their command line or favorite applications without building custom integrations. Polyglot monorepo: cmd/fabric/ contains the main Go CLI entry point, cmd/code2context/ is a specialized Go utility, cmd/generate_changelog/ is a complex Go tool for Git/GitHub automation. A separate Svelte frontend exists (164K lines) for the UI layer. Patterns are crowdsourced in a patterns directory (implied, not shown in file list). Configuration-driven design with .envrc and devcontainer support for reproducible environments.

Power users, developers, and DevOps engineers who want to augment their workflows with AI capabilities without managing multiple SaaS tools. CLI-first users building automation scripts, content creators, security researchers, and contributors curating and sharing reusable AI prompts across the ecosystem.

Actively developed and production-ready: the repo shows recent commits, organized GitHub Actions CI/CD pipelines (.github/workflows/), Docker support, multi-language support (Go CLI, Svelte UI, Python/TypeScript backends), and semantic versioning via GoReleaser. Has established release workflow and changelog generation automation, indicating professional maintenance standards.

Low-to-moderate risk: single primary maintainer (danielmiessler) with ~1M lines of Go code concentration, but mitigated by active CI/CD and community contributions. External dependency risk exists on LLM API providers (not in repo but core to function). The changelog generation tool (cmd/generate_changelog/) shows sophisticated Git/GitHub integration that could break with API changes.

Active development on release automation (update-version-and-create-tag.yaml, release.yaml workflows), patterns synchronization (patterns.yaml workflow), and changelog generation tooling. Appears focused on CI/CD infrastructure hardening and developer experience improvements given the devcontainer setup and workflow improvements visible in .github/workflows/.

git clone https://github.com/danielmiessler/Fabric.git
cd Fabric
# For Go CLI development:
go build ./cmd/fabric
# For full setup with devcontainer (recommended):
open .devcontainer/devcontainer.json  # in VSCode with Dev Containers extension

Daily commands: For the Go CLI: go run ./cmd/fabric or ./fabric (after building). The repo doesn't expose a traditional dev server; it's primarily CLI-driven. For the full system with API server, check cmd/fabric/main.go for available subcommands. Devcontainer setup in .devcontainer/devcontainer.json provides a pre-configured environment with code --remote-containers-try.

• cmd/fabric/main.go: Primary CLI entry point; defines core Fabric commands and workflow orchestration
• cmd/code2context/main.go: Specialized utility for extracting code context; demonstrates Fabric's modular capability pattern
• cmd/generate_changelog/internal/changelog/generator.go: Complex changelog automation logic; shows how Fabric integrates Git/GitHub APIs for intelligent processing
• .github/workflows/ci.yml: CI/CD pipeline definition; reveals testing, build, and release automation strategy
• .goreleaser.yaml: Cross-platform binary release configuration; critical for understanding how Fabric distributes to users
• .devcontainer/devcontainer.json: Reproducible development environment specification; onboarding path for new contributors

Start with cmd/fabric/main.go (entry point) to understand CLI structure. Add new AI task types as patterns in the patterns directory. Extend core Go logic in cmd/fabric/ or cmd/code2context/ for CLI features. For UI changes, edit Svelte components (in the Svelte 164K section, not fully listed). Pattern contributors add YAML definitions to the patterns collection. Configuration-driven changes go in .envrc or config files.

1. The changelog generator (cmd/generate_changelog/) requires GitHub API credentials and Git history access—won't work on fresh clones without git log context. 2) Patterns are crowdsourced externally (not in main repo structure visible in file list)—you'll need to understand how they're fetched/cached. 3) The main fabric CLI likely requires API keys for LLM providers (OpenAI, Claude, etc.)—not set in .envrc by default, causing runtime failures if missing. 4) The Svelte frontend (164K) code isn't detailed in file structure—its integration with the Go backend isn't immediately obvious from the listing.

• Prompt Engineering — Fabric's entire value proposition is organizing and reusing optimized prompts ('patterns')—understanding prompt design, token efficiency, and instruction clarity is core to contributing effective patterns
• Modular Architecture / Plugin Systems — Fabric's patterns are designed as pluggable, discoverable modules; understanding how systems expose capabilities as discrete, composable units is essential for extending Fabric
• LLM Token Budgets & Rate Limiting — Patterns must respect token limits and API rate constraints; cmd/generate_changelog/util/token.go suggests this repo actively manages token budgets to avoid cost/performance issues
• Git & GitHub API Integration — cmd/generate_changelog/ shows sophisticated Git history walking and GitHub API calls; contributors modifying changelog or versioning logic need Git internals and GitHub REST API knowledge
• Cross-Platform Binary Distribution (GoReleaser) — Fabric uses .goreleaser.yaml for multi-OS CLI distribution; understanding how Go binaries are built, tested, and released across platforms is critical for release contributors
• Crowdsourcing & Community Curation — Fabric's patterns are community-contributed; understanding versioning, testing, and validation for crowdsourced content (implied by patterns.yaml workflow) ensures quality control
• DevContainer Specifications — Fabric uses devcontainers (.devcontainer/devcontainer.json) for reproducible environments; Docker and VSCode DevContainers knowledge reduces onboarding friction for new contributors

• openai/gpt-4 — Not a repo, but Fabric patterns are designed to work with OpenAI's models—understanding GPT's prompt engineering is foundational
• facebook/prompt-library — Similar crowdsourced prompt collection; comparison shows Fabric's unique focus on CLI integration and modularity
• langchain-ai/langchain — Ecosystem companion—LangChain provides the LLM chain/orchestration layer that Fabric patterns often wrap for production use
• cli/cli — GitHub's CLI tool; Fabric integrates GitHub APIs (generate_changelog) similar to how gh CLI does, shares patterns for CLI UX design
• huggingface/transformers — If Fabric patterns support local models, this ecosystem provides the model implementations and tokenization utilities underlying advanced pattern behavior

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for cmd/code2context/code.go

The code2context module has code.go and code_test.go, but based on the file structure, test coverage appears minimal for a core utility. This module likely handles critical functionality for converting code into context. Adding edge case tests (empty files, malformed code, various languages, large files) would improve reliability and make contributions safer.

• [ ] Review cmd/code2context/code_test.go to identify untested code paths
• [ ] Add tests for edge cases: empty input, nil pointers, very large files, various file types
• [ ] Add tests for error handling in code.go parsing logic
• [ ] Run go test ./cmd/code2context -cover and aim for >80% coverage
• [ ] Update cmd/code2context/code_test.go with new test cases

Add GitHub Actions workflow for validating pattern YAML structure

The repo contains 100+ patterns in data/patterns/ (each with system.md and user.md files), but there's no automated validation in .github/workflows/ to ensure pattern structure consistency. A patterns.yaml workflow exists but likely doesn't validate individual pattern schemas. Adding validation would catch malformed patterns before merge.

• [ ] Create .github/workflows/validate-patterns.yml workflow
• [ ] Implement schema validation for data/patterns//system.md and data/patterns//user.md files (check required frontmatter, headers, etc.)
• [ ] Add checks that every pattern directory has both system.md and user.md
• [ ] Run validation on pull requests affecting data/patterns/**
• [ ] Document the pattern structure in a new data/patterns/PATTERN_STRUCTURE.md file

Add integration tests for cmd/generate_changelog with mock Git/GitHub data

The generate_changelog tool has internal modules (git, github, changelog) with some unit tests (generator_test.go, processing_test.go, email_test.go), but no integration tests that simulate real Git history + GitHub API responses. This would catch breaking changes when refactoring the changelog generator and increase confidence for contributors.

• [ ] Create cmd/generate_changelog/internal/integration_test.go
• [ ] Mock GitHub API responses in cmd/generate_changelog/internal/github/client_test.go
• [ ] Create test Git repository fixtures in cmd/generate_changelog/testdata/repos/
• [ ] Write end-to-end test: generate changelog from mock repo, verify output format and structure
• [ ] Run full test suite with go test ./cmd/generate_changelog/... -v

• Add test coverage to cmd/code2context/code.go—only code.go and code_test.go exist but test completeness is unclear; adding edge case tests (empty input, malformed code, large files) would improve reliability
• Document the patterns discovery/synchronization mechanism—patterns.yaml workflow exists but README doesn't explain how users find, install, or contribute patterns; a patterns/ directory guide would help
• Implement missing subcommand help text—cmd/fabric/main.go likely has a help system but specific subcommands (seen in usage examples) aren't documented inline; add --help output and examples to key commands

The Fabric codebase shows reasonable security practices with organized structure and CI/CD workflows. However, there are notable gaps: missing dependency manifest analysis prevents assessment of supply chain vulnerabilities, a committed database file could expose sensitive data, and critical files like token handling utilities require code review. The project uses GitHub Actions for automation (good practice), but Docker and environment configuration security cannot be fully assessed without viewing implementation details. Primary recommendations: provide dependency files for vulnerability scanning, ensure sensitive files are properly excluded from version control, and conduct code review of credential handling logic.

• Medium · Potential Hardcoded Credentials in Cache Database — cmd/generate_changelog/changelog.db. The file 'cmd/generate_changelog/changelog.db' appears to be a database file committed to version control. If this contains any sensitive information, credentials, or API tokens, they could be exposed in the repository history. Fix: Remove the database file from version control, add it to .gitignore, and use environment variables or secure configuration management for any sensitive data.
• Low · Missing Sensitive File Protections — .envrc. The .envrc file exists in the repository which typically contains environment variables. While the file structure is visible, the contents aren't shown, but this is a common location for storing sensitive configuration that shouldn't be committed. Fix: Ensure .envrc is in .gitignore and never commit environment files containing secrets. Use .envrc.example as a template instead.
• Low · Potential Token Exposure in Utility Code — cmd/generate_changelog/util/token.go. The file 'cmd/generate_changelog/util/token.go' suggests token handling logic. Without seeing the implementation, this could be a risk vector for credential leakage if not properly secured. Fix: Review token.go to ensure tokens are never logged, printed to stdout, or stored in plain text. Use secure token storage mechanisms and avoid embedding tokens in code.
• Low · Missing Dependency Information — Repository root - missing dependency manifests. No package dependency files (go.mod, go.sum, requirements.txt, package.json, etc.) were provided in the analysis. This prevents assessment of vulnerable dependencies in the supply chain. Fix: Provide and regularly scan go.mod, go.sum files and other dependency manifests using tools like 'go list -json -m all | nancy sleuth' or dependabot for automated vulnerability detection.
• Low · Limited Visibility on Docker Security Configuration — .dockerignore, .devcontainer/devcontainer.json. A .dockerignore file exists but no Dockerfile content was provided for analysis. Docker images could have security issues like running as root, using outdated base images, or including unnecessary files. Fix: Review Dockerfile to ensure: non-root user execution, minimal base images, security scanning in CI/CD pipeline, and proper secret handling during builds.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.