managing-artifacts
Skill11 starsChanged 3 months agoMITView on GitHub
Artifact storage paths and project-encoded conventions for generated documents, reports, plans, and audits. Loaded by the core rule module. Triggers: 'where should I put this', 'save report', 'output directory'.
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 6 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
ALL generated documents, reports, plans, and artifacts MUST be stored outside project directories.
- Distinctive: line 21
Consistent encoding: Always use project-encoded paths for organization
- Distinctive: line 24
Before writing any artifact, determine:
- Distinctive: line 31
After artifact operations, verify:
- Very specific: line 76
If NO_GIT_REPO: Ask user to init, or use fallback: ~/.local/spellbook/docs/_no-repo/$(basename "$PWD")/
- Very specific: line 91
If project has no CLAUDE.md, check: ~/.local/spellbook/docs/<project-encoded>/CLAUDE.md
- Very specific: line 97
Write to ~/.local/spellbook/docs/<project-encoded>/CLAUDE.md instead.
- Distinctive: line 106
When user asks to "add X to CLAUDE.md" for such a project:
- Distinctive: line 108
Write to fallback location instead
- Very specific: line 132
Every artifact you generate belongs in ~/.local/spellbook/, not in the project.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Managing Artifacts
<ROLE>
Artifact Organization Specialist. Your reputation depends on keeping projects clean and artifacts findable. Littering project directories with generated files is a cardinal sin.
</ROLE><CRITICAL>
ALL generated documents, reports, plans, and artifacts MUST be stored outside project directories.
This prevents littering projects with generated files and keeps artifacts organized centrally.
</CRITICAL>Invariant Principles
- Never litter projects: Generated artifacts go to
~/.local/spellbook/, never project directories - Respect shared repos: Multi-contributor projects use fallback paths to avoid polluting the repo
- Consistent encoding: Always use project-encoded paths for organization
<analysis>
Before writing any artifact, determine:
- What type of artifact is this? (plan, audit, report, etc.)
- What is the project-encoded path?
- Is this a multi-contributor project requiring fallback location?
</analysis><reflection>
After artifact operations, verify:
- File was written to correct spellbook directory, not project directory
- Path follows naming conventions (YYYY-MM-DD prefix, etc.)
- User was informed of file location
</reflection>Standard Directory Structure
~/.local/spellbook/
├── docs/<project-encoded>/ # All generated docs for a project
│ ├── encyclopedia.md # Project overview for agent onboarding (deprecated)
│ ├── plans/ # Design docs and implementation plans
│ │ ├── YYYY-MM-DD-feature-design.md
│ │ └── YYYY-MM-DD-feature-impl.md
│ ├── audits/ # Test audits, code reviews, etc.
│ │ └── auditing-green-mirage-YYYY-MM-DD-HHMMSS.md
│ ├── understanding/ # Feature understanding documents
│ │ └── understanding-feature-YYYYMMDD-HHMMSS.md
│ └── reports/ # Analysis reports, summaries
│ └── simplify-report-YYYY-MM-DD.md
├── distilled/<project-encoded>/ # Emergency session preservation
│ └── session-YYYYMMDD-HHMMSS.md
└── logs/ # Operation logs
└── review-pr-comments-YYYYMMDD.logProject Encoded Path Generation
# Find outermost git repo (handles nested repos like submodules/vendor)
_outer_git_root() {
local root=$(git rev-parse --show-toplevel 2>/dev/null)
[ -z "$root" ] && { echo "NO_GIT_REPO"; return 1; }
local parent
while parent=$(git -C "$(dirname "$root")" rev-parse --show-toplevel 2>/dev/null) && [ "$parent" != "$root" ]; do
root="$parent"
done
echo "$root"
}
PROJECT_ROOT=$(_outer_git_root)
PROJECT_ENCODED=$(echo "$PROJECT_ROOT" | sed 's|^/||' | tr '/' '-')
# Result: "Users-alice-Development-myproject"If NO_GIT_REPO: Ask user to init, or use fallback: ~/.local/spellbook/docs/_no-repo/$(basename "$PWD")/
NEVER Write To
| Path | Why |
<project>/docs/ | Project docs are for project documentation |
<project>/plans/ | Reserved for project planning |
<project>/reports/ | Reserved for project reports |
<project>/*.md | Except CLAUDE.md when explicitly requested |
Project-Specific CLAUDE.md
Fallback Lookup
If project has no CLAUDE.md, check: ~/.local/spellbook/docs/<project-encoded>/CLAUDE.md
Open Source Project Handling
<RULE>
For multi-contributor projects, NEVER add instructions to `<project>/CLAUDE.md`.
Write to `~/.local/spellbook/docs/<project-encoded>/CLAUDE.md` instead.
</RULE>Detection (any of):
- Has
upstreamgit remote - Multiple authors (
git shortlog -sn | wc -l > 1) - Has CONTRIBUTING.md
- Is a fork
When user asks to "add X to CLAUDE.md" for such a project:
- Detect if open source/multi-contributor
- Write to fallback location instead
- Inform user: "This appears to be a shared repository. Added to ~/.local/spellbook/docs/..."
Quick Reference
| Artifact Type | Location |
| Design docs | ~/.local/spellbook/docs/<project>/plans/YYYY-MM-DD-feature-design.md |
| Impl plans | ~/.local/spellbook/docs/<project>/plans/YYYY-MM-DD-feature-impl.md |
| Audits | ~/.local/spellbook/docs/<project>/audits/ |
| Reports | ~/.local/spellbook/docs/<project>/reports/ |
| Encyclopedia (deprecated) | ~/.local/spellbook/docs/<project>/encyclopedia.md |
| Session distill | ~/.local/spellbook/distilled/<project>/ |
| Logs | ~/.local/spellbook/logs/ |
<FORBIDDEN>
- Writing generated artifacts to project directories
- Creating docs/, plans/, reports/ folders inside projects
- Adding instructions to CLAUDE.md in multi-contributor repos
- Using relative paths instead of project-encoded paths
- Skipping the open source detection check
</FORBIDDEN><FINAL_EMPHASIS>
Every artifact you generate belongs in ~/.local/spellbook/, not in the project. A clean project is a professional project. There is no excuse for littering — not haste, not convenience, not ambiguity.
</FINAL_EMPHASIS>
In this repository65 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- documentation-updatesSkill
- spellbook-auditingSkill
- advanced-code-reviewSkill
- adversarial-reviewSkill
- agent2agentSkill
- analyzing-domainsSkill
- analyzing-skill-usageSkill
- assembling-contextSkill
- async-await-patternsSkill
- auditing-green-mirageSkill
- autonomous-modeSkill
- branch-contextSkill
- code-reviewSkill
- creating-issues-and-pull-requestsSkill
- debuggingSkill
- dedupeSkill
- deep-researchSkill
- dehallucinationSkill
- design-explorationSkill
- designing-workflowsSkill
- developSkill
- devils-advocateSkill
- dispatching-parallel-agentsSkill
- distilling-prsSkill
- documenting-projectsSkill
- documenting-toolsSkill
- emotional-stakesSkill
- enforcing-code-qualitySkill
- estimating-ticketsSkill
- executing-plansSkill
- fact-checkingSkill
- finding-dead-codeSkill
- finishing-a-development-branchSkill
- fixing-testsSkill
- fractal-thinkingSkill
- gathering-requirementsSkill
- generating-diagramsSkill
- instruction-engineeringSkill
- isolated-testingSkill
- merging-worktreesSkill
- opportunity-awarenessSkill
- optimizing-instructionsSkill
- polish-repoSkill
- reflexionSkill
- requesting-code-reviewSkill
- resolving-merge-conflictsSkill
- reviewing-design-docsSkill
- reviewing-impl-plansSkill
- reviewing-prsSkill
- rounding-up-worktree-sessionsSkill
- sharpening-promptsSkill
- smart-readingSkill
- test-driven-developmentSkill
- testing-strategySkill
- tooling-discoverySkill
- using-git-worktreesSkill
- using-lsp-toolsSkill
- using-skillsSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

