메뉴
Mission decomposition skill — breaks complex tasks into dependency-aware PHASE lines that the orchestrator executes directly, bypassing its internal LLM decomposer. Use when planning missions, creating mission files, or decomposing complex tasks.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Schedules and runs cron jobs and the nanika publishing pipeline via scheduler CLI. Use when scheduling jobs, managing cron tasks, running the daemon, checking job history, or setting up the daily publishing pipeline.
Obsidian vault CLI — read, write, search, capture, triage, enrich, and ingest into the vault at ~/.alluka/vault/. Prefer this CLI over the Write tool for vault paths so the search index, frontmatter schema, and triage hooks stay in sync — plain Write still works and the memory system reads any valid markdown at the canonical paths regardless of how it was produced. Use when user asks about notes, vault, captures, inbox triage, note search, or importing scout/learnings data.
Full article pipeline — from topic research to Substack draft. Scouts trending intel, writes or selects an article, generates intaglio art via Google Flow, creates manifest, and cross-posts to Substack. Use when creating, illustrating, or publishing articles.
Telegram and Discord channel integration for the orchestrator. Handles inbound messages as orchestrator commands and pushes mission lifecycle events back.
Handles inbound Telegram messages as orchestrator commands when running with --channels plugin:telegram@claude-plugins-official
Send native voice messages and text to Discord channels via the discord CLI. Use when sending audio as a Discord voice message or checking channel config.
| name | decomposer |
| description | Mission decomposition skill — breaks complex tasks into dependency-aware PHASE lines that the orchestrator executes directly, bypassing its internal LLM decomposer. Use when planning missions, creating mission files, or decomposing complex tasks. |
| license | MIT |
| metadata | {"author":"joey","version":"1.1.0"} |
Break complex tasks into PHASE lines that the Nanika orchestrator executes directly. When a mission file contains PHASE lines, the orchestrator skips its internal decomposer and runs your phases as-is. This gives you full control over ordering, dependencies, persona selection, and parallelism.
Every phase is a single pipe-delimited line:
PHASE: <name> | OBJECTIVE: <what to accomplish> | PERSONA: <persona-name> | SKILLS: <skill1,skill2> | DEPENDS: <phase-name1,phase-name2>
PHASE — short kebab-case name such as research-options or review-auth-flowOBJECTIVE — a concrete deliverable, not a vague activityPERSONA — exactly one persona from the catalog belowSKILLS — optional, comma-separated; include only when the phase genuinely needs a toolDEPENDS — optional, comma-separated phase names; omit for independent workEach phase gets exactly one persona. If work spans specialties, split it.
BAD: PHASE: build-auth | OBJECTIVE: Design and implement auth | PERSONA: architect
GOOD: PHASE: design-auth | OBJECTIVE: Design the auth flow and token contract | PERSONA: architect
PHASE: implement-auth | OBJECTIVE: Build the auth handlers and persistence layer | PERSONA: senior-backend-engineer | DEPENDS: design-auth
Each phase should deliver a meaningful capability, not a thin layer.
BAD: PHASE: setup-db | OBJECTIVE: Create tables | PERSONA: senior-backend-engineer
GOOD: PHASE: implement-auth | OBJECTIVE: Build auth with schema, handlers, and tests | PERSONA: senior-backend-engineer
Aim for 2-8 phases. Maximum 12. Single-capability tasks may only need 1-2 phases.
State the actual deliverable.
BAD: OBJECTIVE: Research the topic
GOOD: OBJECTIVE: Compare three deployment options with operational trade-offs and a recommendation
Use the narrowest current persona that fits.
academic-researcher only for scholarly, literature-backed, citation-heavy, or methodology-sensitive researcharchitect for technical comparison, system trade-offs, framework selection, and design decisionsdata-analyst for logs, metrics, usage, trends, and quantitative before/after analysistechnical-writer for docs, developer explainers, ADRs, and article-style technical synthesissenior-backend-engineer for backend implementation, CLIs, APIs, storage, and service codesenior-frontend-engineer for React, Next.js, TypeScript, and UI workstaff-code-reviewer, security-auditor, and qa-engineer stay in review/test/audit lanesDo not guess skill names. Omit SKILLS entirely when no skill is required.
If two phases do not consume each other, omit DEPENDS so the orchestrator can run them concurrently.
PHASE: analyze-logs | OBJECTIVE: Identify the endpoints with the highest 500 rate from the last 7 days | PERSONA: data-analyst
PHASE: review-auth | OBJECTIVE: Review the auth middleware for correctness and security regressions | PERSONA: staff-code-reviewer
PHASE: summarize | OBJECTIVE: Produce a rollout recommendation from the log analysis and code review findings | PERSONA: architect | DEPENDS: analyze-logs, review-auth
If a phase needs another phase's output, it MUST declare DEPENDS.
When a mission includes implementation on a repo-backed target, add a downstream staff-code-reviewer phase by default.
Use security-auditor instead only when security is the primary concern.
No filler phases. Add only the work needed to reach the deliverable, plus the required review phase for implementation.
If a writing or architecture phase depends on gathered evidence, it must depend on the research phase.
BAD: PHASE: research | OBJECTIVE: Gather sources | PERSONA: academic-researcher
PHASE: write | OBJECTIVE: Draft the explainer | PERSONA: technical-writer
GOOD: PHASE: research | OBJECTIVE: Gather sources | PERSONA: academic-researcher
PHASE: write | OBJECTIVE: Draft the explainer | PERSONA: technical-writer | DEPENDS: research
If architecture or interface decisions are required first, implementation must depend on the design phase.
Review, QA, or security audit phases that inspect code changes must depend on the implementation phase.
When a persona clearly hands off to another, consider adding a follow-up phase. Only add it when the task benefits from the chain.
| From | To | When |
|---|---|---|
| academic-researcher | technical-writer | Research must become docs, an explainer, or article-style technical synthesis |
| academic-researcher | architect | Research informs a technical decision or recommendation |
| academic-researcher | senior-backend-engineer | Research findings should be implemented |
| architect | senior-backend-engineer | Backend implementation follows the design |
| architect | senior-frontend-engineer | Frontend implementation follows the design |
| senior-backend-engineer | staff-code-reviewer | Code changes should be reviewed |
| senior-backend-engineer | qa-engineer | Implementation needs dedicated test expansion |
| senior-frontend-engineer | qa-engineer | UI changes need focused validation or regression coverage |
| security-auditor | senior-backend-engineer | Findings need remediation |
| data-analyst | technical-writer | Analysis must become a readable report or explainer |
| Persona | Best For |
|---|---|
| academic-researcher | Scholarly research, evidence synthesis, literature review, study critique |
| architect | Technical comparisons, trade-off analysis, architecture, interfaces, system design |
| data-analyst | Logs, metrics, trends, usage analysis, reproducible quantitative summaries |
| devops-engineer | CI/CD, Docker, releases, deployment automation, health checks, observability |
| qa-engineer | Test strategy, regression coverage, fixtures, validation, flaky-test diagnosis |
| security-auditor | Threat modeling, vulnerability review, auth/secret handling, trust-boundary analysis |
| senior-backend-engineer | Backend implementation, CLIs, APIs, storage, migrations, service code |
| senior-frontend-engineer | React/Next.js/TypeScript UI implementation and accessibility fixes |
| staff-code-reviewer | Code review, hidden regression detection, API compatibility, maintainability review |
| technical-writer | READMEs, docs, ADRs, guides, technical explainers, article-style synthesis |
academic-researcher as the Generic Research BucketFramework comparison, API option analysis, and implementation-path research are not automatically academic work.
Use architect or data-analyst unless the task explicitly needs literature, citations, or methodology scrutiny.
If the task requires real architectural decisions, split the design from the implementation.
The active catalog does not include narrative-only writer personas. Use technical-writer for technical communication and explainers.
If phase B consumes phase A's output, add DEPENDS. Silent dependency loss creates bad execution order.
Use senior-frontend-engineer for React/Next.js/TypeScript work and devops-engineer for deployment automation.
Task: "Compare options for storing embeddings locally and recommend one for the orchestrator"
PHASE: compare-storage-options | OBJECTIVE: Compare SQLite, Postgres, and file-backed vector storage for local embeddings with trade-offs and recommendation criteria | PERSONA: architect
PHASE: write-adr | OBJECTIVE: Write an ADR documenting the selected storage approach, trade-offs accepted, and migration implications | PERSONA: technical-writer | DEPENDS: compare-storage-options
Task: "Review the literature on pair programming productivity and turn it into a technical explainer"
PHASE: review-literature | OBJECTIVE: Gather and synthesize the strongest studies on pair programming productivity, methodology quality, and conflicting findings | PERSONA: academic-researcher
PHASE: write-explainer | OBJECTIVE: Write a developer-facing explainer that summarizes the evidence, caveats, and practical takeaways | PERSONA: technical-writer | DEPENDS: review-literature
Task: "Design and implement a plugin loading system for the CLI"
PHASE: design-plugin-system | OBJECTIVE: Define the plugin discovery model, interfaces, lifecycle, and compatibility constraints | PERSONA: architect
PHASE: implement-plugin-system | OBJECTIVE: Build plugin discovery, loading, and validation for the CLI according to the design | PERSONA: senior-backend-engineer | DEPENDS: design-plugin-system
PHASE: review-plugin-system | OBJECTIVE: Review the implementation for correctness, regressions, and maintainability | PERSONA: staff-code-reviewer | DEPENDS: implement-plugin-system
Task: "Fix the flaky HTTP handler tests and improve coverage for edge cases"
PHASE: stabilize-tests | OBJECTIVE: Fix the flaky handler behavior and any production code issues causing nondeterministic failures | PERSONA: senior-backend-engineer
PHASE: expand-coverage | OBJECTIVE: Add focused regression coverage for the flaky cases, edge inputs, and error paths | PERSONA: qa-engineer | DEPENDS: stabilize-tests
PHASE: review-test-fix | OBJECTIVE: Review the fixes and tests for hidden regressions or maintainability issues | PERSONA: staff-code-reviewer | DEPENDS: expand-coverage