init-factory

스타10

포크0

업데이트2026년 7월 6일 09:54

Set up the microfactory for the current project. Interviews the user, writes .microfactory/config.yaml, authenticates the task backend (Jira via acli, GitHub via gh, or a local TODO.md), and starts the work loop. Use when the user wants to initialize, configure, or reconfigure the factory.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

jaksa76

jaksa76/microfactory

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Initialize the Microfactory

Set up the current project so plan-next and implement-next can run continuously. All commands below are examples — adapt them to the user's OS and shell (Windows/macOS/Linux).

1. Interview the user

Ask (with AskUserQuestion where options fit, free text otherwise):

Task backend: jira, github, or todo (a local TODO.md file).
Project identifier: Jira project key (e.g. MYPROJ), GitHub owner/repo, or the path to the TODO file.
Plan by default? If yes, every issue needs an approved plan before implementation (issues labeled skip-plan are exempt). If no, only issues labeled needs-plan go through planning.
Feature branches? If yes, implementation happens on feature/<KEY> branches with a pull request (issues labeled skip-branch are exempt). If no, work lands on the default branch (issues labeled needs-branch still get a branch).
Loop intervals: how often to look for work. Defaults: implementation every 20 minutes, planning every 10 minutes.
This session's role: planner or implementer (the other role runs in a second session).

2. Authenticate the backend

jira: check acli jira auth status. If not authenticated, the user must log in interactively — suggest they run ! acli jira auth login (they will need their site, email, and an API token). Also ask for the Jira site host (e.g. mycompany.atlassian.net). Determine the user's Atlassian account id (visible in acli jira auth status output, or ask the user); it is needed for self-assignment.
github: check gh auth status. If not authenticated, suggest ! gh auth login. Determine the username with gh api user --jq .login.
todo: no authentication. Verify the TODO file exists; if not, offer to create it with a couple of example items (see the todo-tasks skill for the format).

Never write tokens or secrets anywhere — the backend CLIs store their own credentials.

3. Write the configuration file

Create .microfactory/config.yaml in the project root (settings only, no secrets — safe to commit):

backend: jira              # jira | github | todo
project: MYPROJ            # Jira key | owner/repo | path to TODO.md
plan_by_default: false
feature_branches: false
implement_interval: 20m
plan_interval: 10m
# jira backend only:
jira_site: mycompany.atlassian.net
jira_account_id: "712020:abc..."
# github backend only:
github_username: octocat

Include only the keys relevant to the chosen backend. If a config file already exists, show it and ask before overwriting.

4. Start the loop

For the role the user chose for this session, invoke the loop skill:

implementer: /loop <implement_interval> /microfactory:implement-next
planner: /loop <plan_interval> /microfactory:plan-next

Then tell the user how to run the other role in a second Claude Code session in the same project, e.g.:

claude
/loop 10m /microfactory:plan-next

If planning is not used (no plan-by-default and no needs-plan issues expected), a single implementer session is enough — say so instead of prescribing two sessions.

이 저장소의 다른 Skills

같은 저장소

plan-next

jaksa76/microfactory

Run one planning iteration of the microfactory — claim the next planning-eligible issue from the configured backend, explore the codebase, write plans/<KEY>.md, push it, and put the issue up for plan review. Intended as a /loop target (e.g. /loop 10m /microfactory:plan-next); also takes an optional issue key to plan a specific issue.

2026-07-2110

github-tasks

jaksa76/microfactory

GitHub Issues backend operations for the microfactory — find eligible issues, claim one with race verification, view, comment, and transition (statuses are mapped to labels), all via the gh CLI. Used by plan-next and implement-next when the configured backend is github. Not for general GitHub questions.

2026-07-0610

implement-next

jaksa76/microfactory

Run one implementation iteration of the microfactory — claim the next implementation-eligible issue from the configured backend, implement it (following the approved plan if one exists), run the tests, push (directly or via a feature branch + PR), and update the issue. Intended as a /loop target (e.g. /loop 20m /microfactory:implement-next); also takes an optional issue key to implement a specific issue.

2026-07-0610

jira-tasks

jaksa76/microfactory

Jira backend operations for the microfactory — find eligible issues, claim one with race verification, view, comment, and transition, all via the acli CLI. Used by plan-next and implement-next when the configured backend is jira. Not for general Jira questions.

2026-07-0610

todo-tasks

jaksa76/microfactory

Local TODO.md backend operations for the microfactory — find eligible items, claim, comment, and transition by editing checkbox states in a markdown file. Used by plan-next and implement-next when the configured backend is todo. Good for trying out the factory without Jira or GitHub.

2026-07-0610

name	init-factory
description	Set up the microfactory for the current project. Interviews the user, writes .microfactory/config.yaml, authenticates the task backend (Jira via acli, GitHub via gh, or a local TODO.md), and starts the work loop. Use when the user wants to initialize, configure, or reconfigure the factory.

Initialize the Microfactory

Set up the current project so plan-next and implement-next can run continuously. All commands below are examples — adapt them to the user's OS and shell (Windows/macOS/Linux).

1. Interview the user

Ask (with AskUserQuestion where options fit, free text otherwise):

Task backend: jira, github, or todo (a local TODO.md file).
Project identifier: Jira project key (e.g. MYPROJ), GitHub owner/repo, or the path to the TODO file.
Plan by default? If yes, every issue needs an approved plan before implementation (issues labeled skip-plan are exempt). If no, only issues labeled needs-plan go through planning.
Feature branches? If yes, implementation happens on feature/<KEY> branches with a pull request (issues labeled skip-branch are exempt). If no, work lands on the default branch (issues labeled needs-branch still get a branch).
Loop intervals: how often to look for work. Defaults: implementation every 20 minutes, planning every 10 minutes.
This session's role: planner or implementer (the other role runs in a second session).

2. Authenticate the backend

jira: check acli jira auth status. If not authenticated, the user must log in interactively — suggest they run ! acli jira auth login (they will need their site, email, and an API token). Also ask for the Jira site host (e.g. mycompany.atlassian.net). Determine the user's Atlassian account id (visible in acli jira auth status output, or ask the user); it is needed for self-assignment.
github: check gh auth status. If not authenticated, suggest ! gh auth login. Determine the username with gh api user --jq .login.
todo: no authentication. Verify the TODO file exists; if not, offer to create it with a couple of example items (see the todo-tasks skill for the format).

Never write tokens or secrets anywhere — the backend CLIs store their own credentials.

3. Write the configuration file

Create .microfactory/config.yaml in the project root (settings only, no secrets — safe to commit):

backend: jira              # jira | github | todo
project: MYPROJ            # Jira key | owner/repo | path to TODO.md
plan_by_default: false
feature_branches: false
implement_interval: 20m
plan_interval: 10m
# jira backend only:
jira_site: mycompany.atlassian.net
jira_account_id: "712020:abc..."
# github backend only:
github_username: octocat

Include only the keys relevant to the chosen backend. If a config file already exists, show it and ask before overwriting.

4. Start the loop

For the role the user chose for this session, invoke the loop skill:

implementer: /loop <implement_interval> /microfactory:implement-next
planner: /loop <plan_interval> /microfactory:plan-next

Then tell the user how to run the other role in a second Claude Code session in the same project, e.g.:

claude
/loop 10m /microfactory:plan-next

If planning is not used (no plan-by-default and no needs-plan issues expected), a single implementer session is enough — say so instead of prescribing two sessions.