원클릭으로
build
Used to build and execute an approved implementation plan by spinning up agents
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Used to build and execute an approved implementation plan by spinning up agents
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Post or update a comment on a Linear ticket using the Linear MCP server. Accepts a ticket ID (e.g. ENG-123), a Linear ticket URL, or a direct link to an existing comment. Works for both human-authored comments and agent-generated summaries.
Creates a Linear document (the Documents feature, distinct from issues/projects) from context in the current conversation, a plan, or a file. Use when the user wants to write up a doc, spec, RFC, or notes page in Linear and attach it to a team, project, initiative, cycle, or issue.
Used to run githooks, perform code & plan reviews with expert critics, and commit/push verified changes
Creates a Linear project under an initiative from a draft list of tickets, clarifies ambiguity with the human, then creates the project and each ticket via /create-linear-ticket. Use when the user wants to stand up a new project in Linear from a plan, doc, or ticket list.
Used to gather requirements, clarify scope, and create implementation plans for new feature requests or bug fixes
Request an automated review on a GitHub PR. Prompts the human to pick a reviewer (Copilot, Claude, Codex on GitHub, or Codex within Claude Code). Also runs the bot feedback loop: waits for CI/bot reviews, addresses comments, resolves CI failures, then marks draft PRs ready for review.
| name | build |
| description | Used to build and execute an approved implementation plan by spinning up agents |
| disable-model-invocation | false |
STOP. Before doing ANYTHING else — before reading files, before pulling branches, before spinning agents — complete Step 1. It is blocking.
Determine branch strategy first. Resolve the default branch (no network call — use local refs):
DEFAULT_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|origin/||')
# fallback: try network
DEFAULT_BRANCH=${DEFAULT_BRANCH:-$(git remote show origin 2>/dev/null | grep 'HEAD branch' | awk '{print $NF}')}
DEFAULT_BRANCH=${DEFAULT_BRANCH:-main}
Detect current context (for display only):
git rev-parse --git-dir vs git rev-parse --git-common-dir — note if already in a worktree.DEFAULT_BRANCH.Assemble a context line using these two facts independently (they can both be true at once):
Current branch: <name> [on default branch] | [inside worktree]
Then always present this prompt to the human and wait for their reply. If running non-interactively (no human at keyboard), default to Option 1 automatically and log it.
Current branch: <name> [on default branch] | [inside worktree]
How do you want to work on this?
1. Worktree — new git worktree from <DEFAULT_BRANCH> at ../<repo-name>-<branch-name>. Keeps root repo clean.
2. New branch here — create and check out a new branch from <DEFAULT_BRANCH> in this directory (root repo).
3. Reuse current branch/worktree — continue on <current-branch> as-is.
EnterWorktree if available — it switches the agent's working context into the new worktree. If EnterWorktree is unavailable, run git worktree add ../<repo-name>-<branch-name> $DEFAULT_BRANCH and then cd into the new worktree directory before doing any file operations. Create one worktree per branch — agents on the same branch share it. Worktree path convention: ../<repo-name>-<branch-name> (sibling directory, dash-separated). Clean up with git worktree remove after merge or abandonment.git checkout -b <branch-name> $DEFAULT_BRANCH.DEFAULT_BRANCH.Branch name format: kinano/{jira-ticket-id}-{short-description} (max 40 chars for description). If no ticket ID, use kinano/{short-description}.
You will be provided with specific instructions to implement code changes to achieve specific outcomes. Pull the base branch for the affected repos and set up the confirmed branch/worktree from Step 1.
Ask the human to choose from the following options:
Create a todo list for each agent. Kick off the execution.
Once the agent(s) are done, assess whether the changes warrant a modularity review:
/modularity:review against the affected repos before proceeding to critique. Present coupling findings to the human and address any issues before committing.Run /critique with the implementation plan and all impacted repos to ensure changes are reviewed, committed, and pushed.
Do not leave code comments. The code should be simple and self-explanatory. Comments should be used sparingly.