메뉴
Complete release workflow: Validate → Version → Changelog → Commit → Tag → Publish. Use after successful code changes to src/drift/. Single command: `python scripts/release_automation.py --full-release`
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Drift-specific ADR workflow for signal, scoring, output, and architecture decisions. Use when creating, updating, or validating ADRs before implementation. Keywords: ADR, decision record, proposed, signal design, scoring change, architecture boundary, output format, Decision trailer.
Drift-specific workflow for creating, extending, and validating ground-truth fixtures for signal precision and recall. Use when adding TP/TN fixtures, confounders, boundary cases, or file_history_overrides in tests/fixtures/ground_truth.py. Keywords: ground truth, fixture, precision recall, TP, TN, confounder, boundary, file_history_overrides, ALL_FIXTURES.
End-to-end Drift workflow for adding or materially changing a signal. Use when designing a signal, implementing BaseSignal logic, adding weights, creating fixtures, updating audits, and validating precision/recall before commit. Keywords: signal development, BaseSignal, register_signal, incremental_scope, signal design, precision recall, mutation benchmark, audit_results, ADR.
Operationaler Workflow für den internen MCP-Server aus scripts/mcp_product_health_server.py. Immer verwenden, wenn Agenten Produktstatus, Release-Gates, Working-Tree-Gates oder Audit-Freshness direkt per MCP abrufen sollen statt manuelle Git-/Script-Aufrufe zu bauen. Keywords: drift_product_health, drift_release_readiness, drift_working_tree_context, drift_audit_freshness, mcp server, pre-push gates, blast report, audit freshness.
Log learnings, errors, and corrections to .learnings/ for continuous improvement. Use when: (1) A command or operation fails unexpectedly, (2) User corrects the agent, (3) A knowledge gap is identified, (4) A better approach is found. Captures corrections, insights, errors, and feature requests; promotes broadly applicable learnings to project memory files.
Post-completion self-review for coding agents that runs simplify, harden, and micro-documentation passes on non-trivial code changes. Use when: a coding task just completed, the diff touches executable source files with 10+ changed lines or high-impact logic (auth, validation, queries, file paths, network, concurrency). Feeds recurring findings into self-improving-agent via .learnings/LEARNINGS.md.
| name | drift-release |
| description | Complete release workflow: Validate → Version → Changelog → Commit → Tag → Publish. Use after successful code changes to src/drift/. Single command: `python scripts/release_automation.py --full-release` |
Releases are fully automated via python-semantic-release (PSR) in CI.
Agents no longer need to run a manual release command.
Workflow: .github/workflows/release.yml runs on every push to main.
PSR parses conventional commits and handles version bump, changelog, tag, GitHub Release, and PyPI publish.
✅ Know this after:
feat: ... commit)fix: ... commit)BREAKING: ... commit)The CI release workflow handles everything else automatically.
feat: add new detector for X → MINOR bump (0.X.0)
fix: false alarm in signal Y → PATCH bump (0.0.X)
BREAKING: remove deprecated API → MAJOR bump (X.0.0)
make test-fast
PSR in CI handles the rest after push to main.
pyproject.toml (version field)CHANGELOG.md (new entry)chore: Release X.Y.ZvX.Y.Z| Problem | Solution |
|---|---|
| No release after push | Check commit messages use conventional prefixes (feat:, fix:, BREAKING:). Commits without these don't trigger releases. |
| Tests fail during release | Fix code first. PSR only runs when there are releasable commits. |
| Version looks wrong | Verify recent commit messages. PSR Priority: BREAKING > feat > fix. |
| PyPI publish fails | GitHub Release exists. Re-trigger with publish.yml workflow_dispatch. |
| CI unavailable | Local fallback: python scripts/release_automation.py --full-release |
PYPI_RELEASE secret in GitHub environment pypivX.Y.Z (e.g., v1.4.2).github/workflows/release.ymlpyproject.toml → [tool.semantic_release]v1 auto-updated to latest patch (e.g., v1 → v1.4.3)❌ Forget to release after code changes
❌ Skip tests to "speed up" the release
❌ Manually create git tags/commits for releases
❌ Edit version numbers outside of pyproject.toml
❌ Push without running the full release workflow
# Full release (recommended)
python scripts/release_automation.py --full-release
# Just calculate version
python scripts/release_automation.py --calc-version
# Just update changelog
python scripts/release_automation.py --update-changelog
# Skip tests (NOT recommended)
python scripts/release_automation.py --full-release --skip-tests
Reference documentation: .github/instructions/drift-release-automation.instructions.md
For questions about releases → Check that file first.