4-step-program
The 4 Step Program
A coordinator workflow for orchestrating dockeragents. You delegate, they implement. You enforce the loop until quality is achieved.
Platform Detection: This skill adapts to the active platform. See
skills/obsidian-plan-wiki/references/platform-detection.mdfor detection rules and command mapping. When ambiguous, ask: "Are we working with GitHub, Forgejo, or local tickets?"
⚠️ MANDATORY: Review Posting
Every code review MUST be posted to the active platform. This is NOT optional.
- The code-reviewer agent MUST post their review where the human can see it
- A review that is not posted to the platform means the task has FAILED
- The human needs to see the review to evaluate quality before merging
| Platform | Where the review goes |
|---|---|
| GitHub | PR comment via gh pr comment or gh pr review |
| Forgejo | PR comment via Forgejo API |
| Local tk | Review ticket via todos_oneshot(tags: "review") |
More from cygnusfear/agent-skills
file-name-wizard
Audit all filename and naming conventions in the codebase against AGENTS.md standards and common patterns. Use when user asks to check naming conventions, audit filenames, find naming inconsistencies, or validate file naming patterns.
1.2Karchitectural-analysis
Deep architectural audit focused on finding dead code, duplicated functionality, architectural anti-patterns, type confusion, and code smells. Use when user asks for architectural analysis, find dead code, identify duplication, or assess codebase health.
34video-explorer
This skill should be used when analyzing video files. You cannot process video directly, so this skill extracts frames hierarchically - starting with a quick overview, then zooming into regions of interest with higher resolution and temporal density. Use when asked to watch, analyze, review, or understand video content.
34review-changes
Code review of current git changes, compare to related plan if exists, identify bad engineering, over-engineering, or suboptimal solutions. Use when user asks to review changes, check git diff, validate implementation quality, or assess code changes.
33design-spec-extraction
Use when extracting design specifications from visual sources including Figma exports, UI mockups, screenshots, or live website captures. Produces W3C DTCG-compliant JSON with component trees for code generation and developer handoff.
32obsidian-plan-wiki
Create and manage behavior specification wikis in Obsidian format. Use when creating specs, documenting features, or when user mentions "wiki", "spec", "feature", or "Obsidian".
31