Menu
Validate and prepare documentation for GitHub Pages deployment
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | deploy-docs |
| description | Validate and prepare documentation for GitHub Pages deployment |
| disable-model-invocation | true |
Validate the documentation site and prepare it for GitHub Pages deployment.
Run these checks:
# Count components
echo "Agents: $(ls plugins/systematic/agents/*.md | wc -l)"
echo "Skills: $(ls -d plugins/systematic/skills/*/ 2>/dev/null | wc -l)"
# Validate JSON
cat .claude-plugin/marketplace.json | jq . > /dev/null && echo "✓ marketplace.json valid"
cat plugins/systematic/.claude-plugin/plugin.json | jq . > /dev/null && echo "✓ plugin.json valid"
# Check all HTML files exist
for page in index agents commands skills mcp-servers changelog getting-started; do
if [ -f "plugins/systematic/docs/pages/${page}.html" ] || [ -f "plugins/systematic/docs/${page}.html" ]; then
echo "✓ ${page}.html exists"
else
echo "✗ ${page}.html MISSING"
fi
done
git status --porcelain plugins/systematic/docs/
If there are uncommitted changes, warn the user to commit first.
Since GitHub Pages deployment requires a workflow file with special permissions, provide these instructions:
.github/workflows/deploy-docs.yml with the GitHub Pages workflowAfter merging to main, the docs will auto-deploy. Or:
name: Deploy Documentation to GitHub Pages
on:
push:
branches: [main]
paths:
- 'plugins/systematic/docs/**'
workflow_dispatch:
permissions:
contents: read
pages: write
id-token: write
concurrency:
group: "pages"
cancel-in-progress: false
jobs:
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/configure-pages@v4
- uses: actions/upload-pages-artifact@v3
with:
path: 'plugins/systematic/docs'
- uses: actions/deploy-pages@v4
Provide a summary:
## Deployment Readiness
✓ All HTML pages present
✓ JSON files valid
✓ Component counts match
### Next Steps
- [ ] Commit any pending changes
- [ ] Push to main branch
- [ ] Verify GitHub Pages workflow exists
- [ ] Check deployment at https://everyinc.github.io/systematic/
Explore requirements and approaches through collaborative dialogue before writing a right-sized requirements document and planning implementation. Use for feature ideas, problem framing, when the user says 'let's brainstorm', or when they want to think through options before deciding what to build. Also use when a user describes a vague or ambitious feature request, asks 'what should we build', 'help me think through X', presents a problem with multiple valid solutions, or seems unsure about scope or direction — even if they don't explicitly ask to brainstorm.
Create structured plans for any multi-step task -- software features, research workflows, events, study plans, or any goal that benefits from structured breakdown. Also deepen existing plans with interactive review of sub-agent findings. Use for plan creation when the user says 'plan this', 'create a plan', 'write a tech plan', 'plan the implementation', 'how should we build', 'what's the approach for', 'break this down', 'plan a trip', 'create a study plan', or when a brainstorm/requirements document is ready for planning. Use for plan deepening when the user says 'deepen the plan', 'deepen my plan', 'deepening pass', or uses 'deepen' in reference to a plan.
Structured code review using tiered persona agents, confidence-gated findings, and a merge/dedup pipeline. Use when reviewing code changes before creating a PR.
Use when starting any conversation - establishes how to find and use skills, requiring skill tool invocation before ANY response including clarifying questions
Refresh stale or drifting learnings and pattern docs in docs/solutions/ by reviewing, updating, consolidating, replacing, or deleting them against the current codebase. Use after refactors, migrations, dependency upgrades, or when a retrieved learning feels outdated or wrong. Also use when reviewing docs/solutions/ for accuracy, when a recently solved problem contradicts an existing learning, when pattern docs no longer reflect current code, or when multiple docs seem to cover the same topic and might benefit from consolidation.
Document a recently solved problem to compound your team's knowledge