source-command-done
starsforks
How to install source-command-done?
pavel-molyanov/molyanov-ai-dev/source-command-done
$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill source-command-doneConverted Codex workflow from Claude slash command done. Use when the user asks to run the equivalent command or describes this workflow.
SKILL.md
| 1 | <!-- Generated by sync-to-codex v1. Do not edit directly. --> |
| 2 | |
| 3 | # Command Workflow: done |
| 4 | |
| 5 | Treat Claude-only tool names as conceptual workflow steps and use available Codex tools/policies. |
| 6 | |
| 7 | ## Codex Policy Gates |
| 8 | |
| 9 | - Ask before external actions such as GitHub repository creation, `git push`, deploys, or sending messages unless the user explicitly requested that exact action. |
| 10 | - Deployments must go through GitHub CI/CD; direct server access is only for emergency debugging of broken production. |
| 11 | - Never ask the user to paste secrets in chat. Direct them to `.env` files or GitHub Actions secrets. |
| 12 | |
| 13 | # Done — Finalize Feature |
| 14 | |
| 15 | ## Project Documentation Autosync |
| 16 | |
| 17 | If this command changes any project-local `.claude/**` file, immediately run: |
| 18 | |
| 19 | ```bash |
| 20 | ~/.claude/scripts/sync-to-codex.sh --project "$PWD" --apply |
| 21 | ``` |
| 22 | |
| 23 | If sync reports a conflict, stop and report it. Include generated `.codex/**` changes in the same commit as the `.claude/**` source change. |
| 24 | |
| 25 | ## Step 1: Load Documentation Skill |
| 26 | |
| 27 | Use Skill tool: `documentation-writing` |
| 28 | |
| 29 | ## Step 2: Identify Feature |
| 30 | |
| 31 | User typically provides feature directory with the command (e.g., `/done work/my-feature`). |
| 32 | - If provided → use it |
| 33 | - If not → ask: "Which feature to finalize? Provide path to work/{feature}/ directory." |
| 34 | |
| 35 | ## Step 3: Read Feature Artifacts |
| 36 | |
| 37 | Read these files from the feature directory: |
| 38 | 1. `user-spec.md` — what was planned |
| 39 | 2. `tech-spec.md` — how it was implemented |
| 40 | 3. `decisions.md` — what decisions were made during implementation |
| 41 | |
| 42 | If `decisions.md` is missing or sparse, use `git log --oneline` for feature-related commits to understand what changed. |
| 43 | |
| 44 | **Completeness check:** If the feature looks incomplete (tasks not marked done in tech-spec, missing implementation, failing tests) — warn the user: "Feature appears incomplete: {reason}. Continue with finalization anyway?" |
| 45 | |
| 46 | ## Step 4: Update Project Knowledge |
| 47 | |
| 48 | If `.claude/skills/project-knowledge/references/` does not exist or is empty — skip this step, inform the user that project knowledge has not been initialized. |
| 49 | |
| 50 | Otherwise, read current PK files and update only those affected by the feature: |
| 51 | - `architecture.md` — new components, changed structure, data model / schema changes |
| 52 | - `patterns.md` — new project-specific patterns, testing approaches, business rules |
| 53 | - `deployment.md` — deployment or monitoring changes |
| 54 | - If the project has a backlog file, note any status updates for the user |
| 55 | |
| 56 | Apply quality principles from documentation-writing skill: no code examples, no obvious content, only project-specific information. |
| 57 | |
| 58 | ## Step 5: Archive |
| 59 | |
| 60 | Move `work/{feature}/` → `work/completed/{feature}/` (create `work/completed/` if it doesn't exist). |
| 61 | |
| 62 | ## Step 6: Commit & Report |
| 63 | |
| 64 | 1. Commit PK file changes and feature archive move. |
| 65 | ``` |
| 66 | docs: update project knowledge after {feature-name} |
| 67 | ``` |
| 68 | |
| 69 | 2. Report to user: |
| 70 | - What was done (brief summary from specs) |
| 71 | - What PK files were updated and what changed |
| 72 | - Feature archived to `work/completed/{feature}/` |
| 73 | |
| 74 | ## Self-Verification |
| 75 | |
| 76 | - [ ] Documentation-writing skill loaded |
| 77 | - [ ] Feature artifacts read and understood |
| 78 | - [ ] Completeness assessed (user warned if incomplete) |
| 79 | - [ ] PK files updated (only affected ones) |
| 80 | - [ ] Feature archived to work/completed/ |
| 81 | - [ ] Changes committed |
| 82 | - [ ] Report delivered to user |
People who liked this also viewed
6 picksType
- hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026
- request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026
- explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026
- ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
