software-factory-mode-2026aki

Software Factory 2026 Autumn Work Mode

In this session, follow the development flow below. For repo-specific procedures such as how to run the formatter, linter, and tests, and how to prepare dependencies, follow the repo's CLAUDE.md and README.

Checking the execution environment

Before applying the mode, check the execution environment. If any of the following is not satisfied, do not apply the mode, report the unsatisfied condition to the user, and stop:

1. Your own model is at tier Opus or above (Opus, Fable, Mythos, etc.). Lower tiers such as Sonnet and Haiku do not satisfy this even in newer generations
2. If Codex CLI is available, its model is a flagship at Sol or above (Sol, Astra, etc.) and its reasoning effort is medium or higher. Using the Bash tool, run command -v codex to check whether it exists; if it does, write a short prompt to a file outside the working tree and pass it tocodex exec --ephemeral via stdin, run it once, and read from the output header. Lightweight tiers such as Luna and Terra, and models from generations before Sol, are not sufficient as consultation partners

Basic flow

1. Before starting, ask the user about unclear points and concerns, resolve them, and then enter plan mode
2. When a change reaches a stopping point, check for bugs
3. Run the formatter and linter
4. Commit as needed. Do not commit directly to the default branch
5. Wait for the user's explicit instruction to push
6. When instructed to create a PR, create it as a draft, export the conversation context, and write drafts of inline review comments
7. After presenting the drafts, ask the user how to post them. Whether the AI posts them or the user posts them personally
8. For sanity-review, wait for the user's instruction, push the fixes for the pointed-out issues, post a brief comment on what was addressed, and then ready for review
9. Once the PR is switched to ready for review, if that PR allows specifying a commit message with squash and merge, present drafts of the title and body, and state "when instructed, I will squash and merge with these drafts"
10. Once merged, clean up the development environment

Details of each step

Bug check

When a change reaches a stopping point, consult frequently with the codex-consultation skill and check the implementation details. If it is a simple bug, fix it. If there are multiple solutions, ask the user.

In an environment without Codex CLI, fall back to the subagent-consultation skill and clearly state that in the report. Launch the subagent specifying a model at tier Opus or above. If Codex becomes unusable due to usage limits, communication failures, etc., do not fall back; report to the user and ask for their judgment.

How to use Git

• Before committing, check the current branch. If on the default branch, stop without committing, propose a branch name based on the changes, and confirm with the user
• For the branch name, put the most important topic first so it is easy to find via autocomplete or in a list, in the order 対象-性質 . Write each segment in camelCase and connect segments with hyphens. Example: reviewSkills-requireOpusModel
  • fix/ や worktree- Do not add prefixes such as
• git commit --amend or rewinding using reflog. If you judge it necessary, propose it to the user before executing and ask for instructions
• After pushing to a branch that already has a PR, export the conversation context
• After creating a git worktree, prepare dependencies according to the repo's procedure. Copy from the main worktree or install them

Creating a pull request

• Create the PR as a draft. A draft is the state while the implementer is still finishing up, and AI review is completed during this time. Ready for review represents the state where humans can be asked to review, and is not used to mean waiting for AI review
• Follow the repo's PR template for the description
• When you create a child PR, link the parent and child PRs to each other
• When you create a PR, and also when you push after creating it, run the conversation-context-export skill. If you are working in a worktree, set the output destination to the main worktree's.dev/contexts/to
• .dev/contexts/is neither git-managed nor ignored in the repo, do not include the exported file in the commit
• When you create a PR, write a draft of inline review comments for the user to explain the implementation to reviewers, and present it to the user. Focus on important changes and include file names and line numbers

Review

• The person who runs the sanity-review skill is the implementer, not the reviewer. Run it after finishing the description and before asking the reviewer
• Do not skip sanity-review because of the size of the change. Even a one-line fix often gets multiple issues pointed out
• It is desirable to run sanity-review after posting inline review comments. It provides material for checking the consistency between the implementer's explanation in the comments and the implementation
• When asked to do a sanity-review in the session where you developed, launch a subagent of Opus tier or higher that does not inherit the development session's conversation history. Pass only the PR URL, execution conditions, and report output destination to the subagent. Fix the output destination to both chat and the pull request. Also include in the instructions that the skill's fallback procedure must not be used
• Prerequisites for sanity-review: the conversation context has been posted as PR comments. Codex CLI exists on the same machine, and the model and reasoning effort satisfy the conditions in "Checking the execution environment". If Codex CLI is not available, do not run it, and if consultation with Codex fails, abort. Use Opus tier or higher. Sonnet cannot review
• Keep the PR as a draft until the sanity-review is done. After finishing pushing responses to the feedback, the implementer switches it from draft to ready for review.

Cleaning up the development environment

• Stop any development servers or containers you started once the work that uses them—such as visual checks, tests, lint, or consultations with Codex—is finished. Start them again when needed.
• Do not stop things started by other worktrees or sessions until the user instructs you to.
• Once merged, delete the worktree and branch used for the work. Also delete any docker volumes, images, etc. created specifically for the worktree. Leave those of the main worktree.
• Once merged, make the main worktree's default branch follow the remote's default branch. If any of the following applies, do not make it follow and report the reason
  • The main worktree is on a branch other than the default branch
  • There are uncommitted changes to tracked files in the main worktree, or there are untracked files that would be overwritten by following
  • The main worktree is being used by a running container, development server, or test
  • Another session is running work in the main worktree. Do not count sessions that are stopped waiting for input

Things to follow throughout the entire procedure

How to write comments in source code

Read the kuden:code-comment skill and follow its standards.

How to write Agent Skills

Read the kuden:agent-skill skill and follow its standards.

How to write text that appears in pull requests and on GitHub

Read the kuden:github skill and follow its standards.

How to write software tests

Read the kuden:software-test skill and follow its standards.

Linking with the source document of the instructions

Do this when the source of the task's instructions is in a document such as a work page, issue, or ticket. Follow the project's conventions for notation and how states are represented, and match existing descriptions.

• When you start work, write on the source of the instructions that you have started
• Write the URL of the source of the instructions in the PR overview, and add a link to the PR in the source of the instructions
• At each point—creating the draft PR, ready for review, and merge—synchronize the state of the source of the instructions and the parent task summary page that contains it. For merge, reflect it only after confirming that it was actually merged

Editing shared text

When editing a PR overview or a shared document, fetch the latest version immediately beforehand, confirm that it has not changed from the version you based your work on, and then write. If it has changed, reapply your changes on top of the latest version.