archwall 把架构画全Every architecture, drawn in full

idd-skills：AI 一次做一个 GitHub issue，把产品做出来idd-skills: AI builds your product one GitHub issue at a time

coding-agentskillsgithubworkflowgit

idd-skills overview: in comes your product idea, or code you already have; 1 plan: /idd-plan, from an idea or from existing code, writes into a private PRD repo with PRD.md and PROGRESS.md, and picks one next issue in dependency order; 2 build one issue: /idd-issue files it after a duplicate search, /idd-implement makes a branch, tests and a PR into dev, and never merges, which is /idd-land's job; an optional review before landing comes from /peerreview, a separate skill; 3 land: /idd-land checks, then squashes into dev, the issue is closed and the branch deleted, and the tracker update goes into a batch PR in the PRD repo; a dashed arrow goes back to plan for the next round, and /idd-auto loops on its own; 4 finish, once all have landed: /idd-acceptance tests the whole product end to end, /idd-promote moves dev to main with one merge commit when you choose, and the optional /idd-publish makes the code public while the PRD stays private; /idd routes one request to the phase that owns it, and /idd-evolve improves the method itself

idd-skills 是十个技能，让 AI 编程助手一次做一个 GitHub issue，把软件做出来。固定的 git 和 GitHub 步骤归脚本。

工具包在 Claude Code、Codex、Pi 或 OpenCode 里跑。

The kit: it runs inside Claude Code, Codex, Pi or OpenCode; 1 ten skills, plain text: /idd, /idd-plan, /idd-issue, /idd-implement, /idd-land, /idd-auto, /idd-acceptance, /idd-promote, /idd-publish and /idd-evolve; 2 bundled scripts they run: repo setup and merges (init-*.sh, land.sh, promote.sh), branch rules on GitHub (protect-main.sh), and gates for PRD size, the tracker, line width and exposure; fixed steps are scripts, judgment stays in the skill text; 3 GitHub, through git and gh: the scripts run the fixed steps, and the agent follows the skill text for issues, pull requests and visibility; per product a code repo, plus a private PRD repo for planning; 4 rules in the box: CONSTITUTION.md, how the method may change, conventions.md, names, branches and line width, and size caps of 60 to 160 lines for each skill file; validate.sh checks them and runs before every commit; install all ten with npx skills add maximalfocus/idd-skills --skill '*'
工具包：十个技能、配套脚本和规则文件，在你的编程助手里运行

两个仓库。 代码在 {project}，需求和进度在私有 {project}-prd。

Two repos: one product, two GitHub repositories, cloned side by side; 1 {project}, the code: code, tests and docs, the product itself; issues and PRs, one PR for each issue; branches dev, main and issue/<N>-<slug>; private when IDD creates it, and /idd-publish can make it public; 2 {project}-prd, the plan: PRD.md with requirements, slices and non-goals, PROGRESS.md with what is ready, active or blocked, and one branch, main, changed by pull request; always private, never published; the PRD side sends the next issue to the code side and landed work flows back; 3 how they find each other: sibling folders such as widget and widget-prd, the same GitHub owner checked from both origins, or for another owner the setting git config idd.prdRepo; with no PRD repo issues still work and landing skips the tracker; 4 who is right about what: GitHub about what happened (issues, PRs, merges), PRD.md about what is wanted, and PROGRESS.md is checked evidence, not permission; commits, issues and PRs never name the private PRD repo; for a new product the PRD repo comes first, and /idd-auto can create the code repo, private
两个仓库：一个放代码，一个私有，放需求和进度

分支。 issue 的 PR 压缩合并进 dev。main 只靠可选的 /idd-promote 用合并提交推进。

Branches: delivery phases start with protect-main.sh ensure; 1 dev, integration: one issue/<N>-<slug> branch per issue, dev is the default branch every issue PR targets, squash only with one commit per issue PR, and linear history with no force-push and no deletion; 2 main, release: only the optional /idd-promote changes it, with one dev to main PR, merged as a merge commit so main never drifts from dev, and only when CLEAN; the flag --open-only waits for review; promoting is not deploying, nothing is hosted or published; 3 the PRD repo has main only: the tracker through a progress/batch PR merged at milestones, contract changes through your own docs(prd) PR on prd/<slug>, and a local pre-push hook refuses a direct push; it never uses dev, and the first commit at bootstrap is its only direct push; 4 set up by protect-main.sh: PR required, no bypass, review threads resolved; a private repo gets the settings only and the rules once public; opt out of dev with the line Integration-branch: main; set at bootstrap, checked before every landing; names are rules too: PR title equals issue title, typed commit subjects, lines of at most 100 characters
分支：issue 合进 dev，main 只能通过 /idd-promote 前进

一个入口。 /idd 把一个请求交给该管它的阶段。合并、公开这类大事，你点名才做。

The way in: you type /idd and a request, for example /idd 6; 1 orient first: protect-main.sh ensure prints the integration and release branches; read the request: an issue number, a PRD pair, a phase named; load that one phase's SKILL.md and run it in full; if a skill it needs is missing it stops and names it; 2 can be inferred: an issue number or URL goes to /idd-implement, what to do next goes to /idd-plan, read-only, and checking the finished product goes to /idd-acceptance; 3 only when you name it: /idd-issue, /idd-land, /idd-auto, /idd-promote, /idd-publish, /idd-evolve, and the /idd-plan modes bootstrap, reconstruct and reconcile; never from state, history or an earlier turn; 4 routing adds no authority: if two fit or none does it asks one question and never guesses, one phase per request, the same gates as calling the phase directly, and it says which phase it chose and why in one line; no PRD pair yet is a question, never a reason to bootstrap
入口：/idd 把请求交给一个阶段，路由不增加权限

规划。 /idd-plan 从想法或现有代码写 PRD，再挑下一个 issue。

Planning: /idd-plan picks its mode from what exists, no PRD yet or an exact pair; 1 new product, greenfield: ask about the product one decision at a time, draft PRD.md and PROGRESS.md with small slices in dependency order, and push a private, protected repo, or just drafts if you ask; it picks the tech itself unless that changes the product or you state a preference; 2 existing code, reconstruct: read the whole repo with code, tests, docs and history, describe what it does at one named commit, and keep one verified baseline, since past commits never become slices; the flag --scope <paths> is for a repo too big to read at once; both push the PRD and go on in default mode; 3 default, what next: read the PRD, tracker and GitHub, read-only, pick one next issue in dependency order, and write an issue contract with outcome, acceptance and non-goals; 4 reconcile, the tracker: the flag --reconcile, or automatically after /idd-land; edit PROGRESS.md only, never PRD.md; gates, then the batch PR, merged at a milestone; stale requirement text is reported and fixed by your own docs(prd) PR; after landing, default leads to reconcile and back to default for the next issue; no mode writes a plan file or a backlog, and there is at most one next issue
规划：四种模式，按已有的东西选

PRD 有字数上限。验证过的切片并回需求，PRD 不会越写越长。产品大到一份 PRD 装不下，就拆成上下文。

The contract: inside the private {project}-prd; 1 PRD.md, one coherent model: requirements with stable IDs, the accepted behaviour; slices, small, in order, one issue each; the domain boundary with explicit non-goals; preserved artifacts, the files a rewrite must keep; 2 PROGRESS.md, a control panel with the same IDs: status per slice, ready, active, blocked or missing acceptance; a baseline of what is done and verified; an update rule for how rows may change; no dates in table cells, since Git and GitHub keep the history; 3 budgets checked by scripts: PRD.md at most 1,000 words a section and 10,000 in all, PROGRESS.md at most 80 words a cell and a baseline of at most 20 lines; changed only by /idd-evolve, never per project; set from 4 real contracts and 11 trackers; 4 a slice, once validated: its acceptance moves into the requirement it extends or becomes a new one, the slice shrinks to one row in the slices table, and the fold gate flags a slice still holding a section; the PRD grows with the model, not with the number of deliveries; a product too large for one coherent contract splits its PRD into contexts, each with its own scope
需求文档：PRD.md 和 PROGRESS.md 装什么，限多少字
Contexts: when a product is too large for one coherent PRD, the private PRD is partitioned into contexts; 1 the root contract: an index PRD.md with the Contexts table, a portfolio panel with a row for every context, and the manifest and cross-context invariants; a context is admitted only when work is planned there; 2 one context: contexts/<name>/PRD.md and PROGRESS.md, its own scope of implementation paths, the contexts it depends on without restating them, and its own non-goals; 3 kept in step: an issue carries its context name as a label, changed files resolve to that context, one context per issue, dependency first, and a change that crosses contexts is a design decision in the index first; 4 modes and gates: the flag --context <name> works on one context at a time, the contract gate runs over the index and then every context, and the portfolio picks active work or the earliest unmet dependency; acceptance goes context by context, plus the index's cross-context invariants
上下文：产品大到一份 PRD 装不下，就拆成索引和每块的 PRD

建 issue。 /idd-issue 先查重，再建一个 issue。

Filing an issue: you ask to file, create or open one issue; 1 pin it down: which repo, from the flag --repo, a URL or this checkout; search open and closed issues, and on a likely duplicate stop and return it; only the evidence needed, no made-up paths or labels; one question only if scope or behaviour is really unclear; 2 draft it small: a title that states the outcome with no type prefix, number or IDs; problem and evidence; acceptance criteria, each one testable; non-goals only if they prevent confusion; 3 gate before creating: one coherent issue small enough for one run; claims backed by evidence, with criteria enough to judge done; fits the product model, or names a design decision; nothing private, no credentials, account names or home paths; 4 create once, read back: gh issue create with the body from a file; on an unclear result, search before any retry; read it back and check repo, title, body and OPEN; a request to draft or suggest creates nothing, and /idd-auto may file its one next issue
建 issue：只在你要求时建，先查重，建完读回来核对

实现。 /idd-implement 改动最小，在真跑的地方测，再开 PR，从不合并。

Implementing: in comes one open issue, read with its comments; 1 safe start: protect-main.sh ensure, so PRs target dev; issue and comments, which must be OPEN and in the same repo; the branch issue/<N>-<slug>, never the default branch; with a dirty tree it asks, or works in a separate worktree; 2 small change: a plan in chat with outcome, checks and non-goals; trace the path from entry point through logic to result; the smallest coherent diff, following existing patterns; tests at the boundary, a regression test for a bug; 3 verify, cheapest first: unit and regression tests, typecheck and lint, integration and the repo gate, then the changed boundary itself: container, CLI, route or browser; 4 open the PR: commit only the issue's files, typed subjects, lines of at most 100; a PR into dev titled exactly like the issue; a Delivery-Type line; Closes #N only if all is proven; it never merges, deploys or closes the issue by hand; a red check is fixed if new, proven red before, or named as the blocker
实现：从安全的分支到开 PR，到此为止

落地。 /idd-land 检查 PR，压缩合并，关 issue，删分支。

Landing: you run /idd-land with an issue, and /idd-auto and /idd-publish may also call it; 1 refuse early: clean tree, right repo, exactly one linked PR; checks green, not a draft, no changes requested; find the tracker row before touching GitHub; anything ambiguous stops before GitHub changes; 2 acceptance gate: every item proven from the PR, tests and current code; fits the product model with no unrecorded detours; not proven means stop, and only the flag --accept-residuals goes on, a flag that never overrides red checks, requested changes or conflicts; 3 land.sh, one script: names, protection and width checked, PR title equals the issue title and the branch is issue/<N>-<slug>; the subject comes from Delivery-Type, for example fix: <issue title> (#PR); squash into dev, bound to the checked commit; close the issue, delete the branch, pull dev and verify all; 4 then the tracker: the tracker gate keeps PROGRESS.md within budget, /idd-plan reconcile commits to the batch PR, and if this fails the merge stands and it is reported; with no PRD repo it reports not configured; land.sh is read whole before it runs, so a checkout that changes can't alter it
落地：唯一会合并的一步，然后更新进度

进度。 每次落地更新进一个批量 PR，到里程碑才合并。

Progress: in come a landed issue, its PR and its squash commit; 1 who writes: /idd-land after every merge, automatically; /idd-plan with the flag --reconcile to repair or resync; /idd-publish for the publication row; only PROGRESS.md, never PRD.md; 2 checks first: the tracker gate with 80-word cells and no dates in cells, the PRD size and fold gates, which only report, manifest drift with no unlisted files, and line width of at most 100 characters; 3 one open batch PR: the branch progress/batch with docs(progress) commits; it stays open for review and each update adds a commit; two batches open means stop until there is one; 4 merged at a milestone: a slice validated or a release finished, before acceptance or before publishing, at the end of /idd-auto, or your own --reconcile; with changes requested or threads open it exits with code 2, awaiting review; a pre-push hook refuses direct pushes to the PRD's main, skipped if the clone has its own hooks
进度：所有更新进一个批量 PR，到里程碑才合并

自动。 /idd-auto 反复规划、建 issue、实现、落地，直到 PRD 做完再验收。红了就停。

Auto: you run /idd-auto with a project, once; 1 bind the target: the exact PRD and code pair, and a missing code repo is made, private; read the PRD, tracker and GitHub fresh at every turn; done means every requirement landed or validated, and also clean trees with no branch or batch left open; 2 one issue at a time: resume active work before starting new; /idd-plan, then /idd-issue for the one next issue; /idd-implement, which waits for checks and reviews; /idd-land to merge, close and reconcile; a dashed arrow loops back for the next issue; 3 then the whole product, when none are left: merge the tracker batch; /idd-acceptance, a required final gate; a product bug becomes one repair issue under the same slice, back into the loop; a new feature stops for your OK, and the PRD changes first; 4 stops, never bends: a red check, a conflict or an open choice becomes one precise blocker; if you can clear it, one question, then resume; it never publishes, promotes or accepts residuals; no trace file, each turn reads GitHub and the PRD again; finishing ends its authority, and a later request needs its own go-ahead
自动：一次一个 issue，循环到 PRD 做完，再验收

验收。 /idd-acceptance 在用户用的地方测成品：浏览器、API、命令行、容器。

Acceptance: in comes a finished pair, every issue landed, trees clean; 1 bind: the exact pair, all landed, no open issue, PR or branch; a tracker batch still open means stop and reconcile it first; PRD outcomes become journeys, plus whole-product checks; unit tests alone are never the final boundary; 2 the real boundary: a browser through Playwright, by role and label; an HTTP service as its real process with real dependencies; a CLI or library in a fresh setup with pinned output; a container, worker or migration, waiting for health, with throwaway state; 3 run it: a clean or seeded start, waiting for readiness with no fixed sleeps; every journey, a bad path, and a restart when it matters; preserved artifacts exist and match their row; always tear down, even after a failure; 4 PASS, or FAIL by kind: a product bug becomes one normal repair issue; bad fixture or data is fixed and run again; an unclear spec stops and asks for a clear contract; an environment problem is reported as the exact blocker; it never deploys, merges, edits the PRD or weakens a test
验收：在用户真正使用的地方测整个产品，失败要分类

公开。 /idd-publish 扫遍历史，查密钥和私有名称，再只公开代码。

Publishing: you run /idd-publish with a project, explicitly; 1 prepare, still private: reconcile the tracker at this pre-publish milestone; one preparation issue through plan, issue, implement and land; a license, MIT by default, green tests and an end-to-end check; the preparation change is scanned before it is pushed; 2 scan every commit: every commit message and every file on every ref; old PR refs too, since GitHub keeps them; secrets and private names from a built-in list plus your terms; a hit in a commit message can't be purged, so it takes a new repo, or you accept it knowingly; 3 check by hand: issues, comments, reviews and their edit history; Actions runs, logs and artifacts; branches, tags, releases, metadata, and package and doc links; any match blocks the visibility change; 4 flip and verify: the code repo becomes public and the PRD repo stays private; a signed-out check finds the code readable and the PRD denied; re-applied protection means the rulesets are now enforced; publishing is not deploying: no hosting, release or package
公开：先在私有状态下准备、全面扫描，再只公开代码仓库

进化。 /idd-evolve 只为证明过的教训改方法，走评审的 PR。没通过不留痕迹。

Evolving: in comes evidence from real runs, or a simplify pass; 1 evidence: post-plan, issue order and tracker accuracy; post-create, how an issue was written; post-issue, one issue's diff, checks and PR; simplify, merge, compress and delete; 2 the gate is the constitution: proven and high value, not already covered; smaller than the friction, delete before adding; past issues the same or better, naming the one it could hurt; size caps of 60 to 160 lines per skill file; 3 pass: the smallest edit with validate.sh passing; propose.sh opens a PR on evolve/<slug> and never writes main; the maintainer reviews, and land-evolution.sh merges on their word; skills linked to the checkout keep serving main until it lands; 4 fail: nothing happens, no log and no queue, and git history is the only record; new features don't come this way, they go through the PRD and an issue; one reproduced defect is proof enough, advice on behaviour needs several runs
进化：证明过的教训走评审过的 PR，其余什么都不留

idd-skills is ten skills that have an AI coding agent build software one GitHub issue at a time. Scripts do the fixed git and GitHub steps.

The kit runs in Claude Code, Codex, Pi or OpenCode.

The kit: it runs inside Claude Code, Codex, Pi or OpenCode; 1 ten skills, plain text: /idd, /idd-plan, /idd-issue, /idd-implement, /idd-land, /idd-auto, /idd-acceptance, /idd-promote, /idd-publish and /idd-evolve; 2 bundled scripts they run: repo setup and merges (init-*.sh, land.sh, promote.sh), branch rules on GitHub (protect-main.sh), and gates for PRD size, the tracker, line width and exposure; fixed steps are scripts, judgment stays in the skill text; 3 GitHub, through git and gh: the scripts run the fixed steps, and the agent follows the skill text for issues, pull requests and visibility; per product a code repo, plus a private PRD repo for planning; 4 rules in the box: CONSTITUTION.md, how the method may change, conventions.md, names, branches and line width, and size caps of 60 to 160 lines for each skill file; validate.sh checks them and runs before every commit; install all ten with npx skills add maximalfocus/idd-skills --skill '*'
The kit: ten skills, bundled scripts and rule files, run inside your coding agent

Two repos. Code lives in {project}. Requirements and the tracker live in a private {project}-prd.

Two repos: one product, two GitHub repositories, cloned side by side; 1 {project}, the code: code, tests and docs, the product itself; issues and PRs, one PR for each issue; branches dev, main and issue/<N>-<slug>; private when IDD creates it, and /idd-publish can make it public; 2 {project}-prd, the plan: PRD.md with requirements, slices and non-goals, PROGRESS.md with what is ready, active or blocked, and one branch, main, changed by pull request; always private, never published; the PRD side sends the next issue to the code side and landed work flows back; 3 how they find each other: sibling folders such as widget and widget-prd, the same GitHub owner checked from both origins, or for another owner the setting git config idd.prdRepo; with no PRD repo issues still work and landing skips the tracker; 4 who is right about what: GitHub about what happened (issues, PRs, merges), PRD.md about what is wanted, and PROGRESS.md is checked evidence, not permission; commits, issues and PRs never name the private PRD repo; for a new product the PRD repo comes first, and /idd-auto can create the code repo, private
Two repos: one for the code, one private for requirements and progress

Branches. Issue PRs squash into dev. main moves only through the optional /idd-promote, as one merge commit.

Branches: delivery phases start with protect-main.sh ensure; 1 dev, integration: one issue/<N>-<slug> branch per issue, dev is the default branch every issue PR targets, squash only with one commit per issue PR, and linear history with no force-push and no deletion; 2 main, release: only the optional /idd-promote changes it, with one dev to main PR, merged as a merge commit so main never drifts from dev, and only when CLEAN; the flag --open-only waits for review; promoting is not deploying, nothing is hosted or published; 3 the PRD repo has main only: the tracker through a progress/batch PR merged at milestones, contract changes through your own docs(prd) PR on prd/<slug>, and a local pre-push hook refuses a direct push; it never uses dev, and the first commit at bootstrap is its only direct push; 4 set up by protect-main.sh: PR required, no bypass, review threads resolved; a private repo gets the settings only and the rules once public; opt out of dev with the line Integration-branch: main; set at bootstrap, checked before every landing; names are rules too: PR title equals issue title, typed commit subjects, lines of at most 100 characters
Branches: issues land on dev; main moves only through /idd-promote

One way in. /idd sends one request to the phase that owns it. Merging, publishing and other big steps run only when you name them.

The way in: you type /idd and a request, for example /idd 6; 1 orient first: protect-main.sh ensure prints the integration and release branches; read the request: an issue number, a PRD pair, a phase named; load that one phase's SKILL.md and run it in full; if a skill it needs is missing it stops and names it; 2 can be inferred: an issue number or URL goes to /idd-implement, what to do next goes to /idd-plan, read-only, and checking the finished product goes to /idd-acceptance; 3 only when you name it: /idd-issue, /idd-land, /idd-auto, /idd-promote, /idd-publish, /idd-evolve, and the /idd-plan modes bootstrap, reconstruct and reconcile; never from state, history or an earlier turn; 4 routing adds no authority: if two fit or none does it asks one question and never guesses, one phase per request, the same gates as calling the phase directly, and it says which phase it chose and why in one line; no PRD pair yet is a question, never a reason to bootstrap
The way in: /idd hands a request to one phase and adds no authority

Plan. /idd-plan writes the PRD from your idea or from existing code, then picks one next issue.

Planning: /idd-plan picks its mode from what exists, no PRD yet or an exact pair; 1 new product, greenfield: ask about the product one decision at a time, draft PRD.md and PROGRESS.md with small slices in dependency order, and push a private, protected repo, or just drafts if you ask; it picks the tech itself unless that changes the product or you state a preference; 2 existing code, reconstruct: read the whole repo with code, tests, docs and history, describe what it does at one named commit, and keep one verified baseline, since past commits never become slices; the flag --scope <paths> is for a repo too big to read at once; both push the PRD and go on in default mode; 3 default, what next: read the PRD, tracker and GitHub, read-only, pick one next issue in dependency order, and write an issue contract with outcome, acceptance and non-goals; 4 reconcile, the tracker: the flag --reconcile, or automatically after /idd-land; edit PROGRESS.md only, never PRD.md; gates, then the batch PR, merged at a milestone; stale requirement text is reported and fixed by your own docs(prd) PR; after landing, default leads to reconcile and back to default for the next issue; no mode writes a plan file or a backlog, and there is at most one next issue
Planning: four modes, picked by what already exists

The PRD has word budgets. A validated slice folds into its requirement, so the PRD stays small. A product too large for one coherent contract splits its PRD into contexts.

The contract: inside the private {project}-prd; 1 PRD.md, one coherent model: requirements with stable IDs, the accepted behaviour; slices, small, in order, one issue each; the domain boundary with explicit non-goals; preserved artifacts, the files a rewrite must keep; 2 PROGRESS.md, a control panel with the same IDs: status per slice, ready, active, blocked or missing acceptance; a baseline of what is done and verified; an update rule for how rows may change; no dates in table cells, since Git and GitHub keep the history; 3 budgets checked by scripts: PRD.md at most 1,000 words a section and 10,000 in all, PROGRESS.md at most 80 words a cell and a baseline of at most 20 lines; changed only by /idd-evolve, never per project; set from 4 real contracts and 11 trackers; 4 a slice, once validated: its acceptance moves into the requirement it extends or becomes a new one, the slice shrinks to one row in the slices table, and the fold gate flags a slice still holding a section; the PRD grows with the model, not with the number of deliveries; a product too large for one coherent contract splits its PRD into contexts, each with its own scope
The contract: what PRD.md and PROGRESS.md hold, and their word budgets
Contexts: when a product is too large for one coherent PRD, the private PRD is partitioned into contexts; 1 the root contract: an index PRD.md with the Contexts table, a portfolio panel with a row for every context, and the manifest and cross-context invariants; a context is admitted only when work is planned there; 2 one context: contexts/<name>/PRD.md and PROGRESS.md, its own scope of implementation paths, the contexts it depends on without restating them, and its own non-goals; 3 kept in step: an issue carries its context name as a label, changed files resolve to that context, one context per issue, dependency first, and a change that crosses contexts is a design decision in the index first; 4 modes and gates: the flag --context <name> works on one context at a time, the contract gate runs over the index and then every context, and the portfolio picks active work or the earliest unmet dependency; acceptance goes context by context, plus the index's cross-context invariants
Contexts: a product too large for one coherent PRD splits it into an index and per-context PRDs

Issue. /idd-issue files one issue, after a duplicate search.

Filing an issue: you ask to file, create or open one issue; 1 pin it down: which repo, from the flag --repo, a URL or this checkout; search open and closed issues, and on a likely duplicate stop and return it; only the evidence needed, no made-up paths or labels; one question only if scope or behaviour is really unclear; 2 draft it small: a title that states the outcome with no type prefix, number or IDs; problem and evidence; acceptance criteria, each one testable; non-goals only if they prevent confusion; 3 gate before creating: one coherent issue small enough for one run; claims backed by evidence, with criteria enough to judge done; fits the product model, or names a design decision; nothing private, no credentials, account names or home paths; 4 create once, read back: gh issue create with the body from a file; on an unclear result, search before any retry; read it back and check repo, title, body and OPEN; a request to draft or suggest creates nothing, and /idd-auto may file its one next issue
Filing an issue: only when asked, after a duplicate search, then read back

Implement. /idd-implement makes the smallest change, tests it where it really runs, and opens a PR. It never merges.

Implementing: in comes one open issue, read with its comments; 1 safe start: protect-main.sh ensure, so PRs target dev; issue and comments, which must be OPEN and in the same repo; the branch issue/<N>-<slug>, never the default branch; with a dirty tree it asks, or works in a separate worktree; 2 small change: a plan in chat with outcome, checks and non-goals; trace the path from entry point through logic to result; the smallest coherent diff, following existing patterns; tests at the boundary, a regression test for a bug; 3 verify, cheapest first: unit and regression tests, typecheck and lint, integration and the repo gate, then the changed boundary itself: container, CLI, route or browser; 4 open the PR: commit only the issue's files, typed subjects, lines of at most 100; a PR into dev titled exactly like the issue; a Delivery-Type line; Closes #N only if all is proven; it never merges, deploys or closes the issue by hand; a red check is fixed if new, proven red before, or named as the blocker
Implementing: from a safe branch to an open PR, and no further

Land. /idd-land checks the PR, squash-merges it, closes the issue and deletes the branch.

Landing: you run /idd-land with an issue, and /idd-auto and /idd-publish may also call it; 1 refuse early: clean tree, right repo, exactly one linked PR; checks green, not a draft, no changes requested; find the tracker row before touching GitHub; anything ambiguous stops before GitHub changes; 2 acceptance gate: every item proven from the PR, tests and current code; fits the product model with no unrecorded detours; not proven means stop, and only the flag --accept-residuals goes on, a flag that never overrides red checks, requested changes or conflicts; 3 land.sh, one script: names, protection and width checked, PR title equals the issue title and the branch is issue/<N>-<slug>; the subject comes from Delivery-Type, for example fix: <issue title> (#PR); squash into dev, bound to the checked commit; close the issue, delete the branch, pull dev and verify all; 4 then the tracker: the tracker gate keeps PROGRESS.md within budget, /idd-plan reconcile commits to the batch PR, and if this fails the merge stands and it is reported; with no PRD repo it reports not configured; land.sh is read whole before it runs, so a checkout that changes can't alter it
Landing: the one step that merges, then the tracker update

Progress. Each landing adds a tracker update to one batch PR, merged only at milestones.

Progress: in come a landed issue, its PR and its squash commit; 1 who writes: /idd-land after every merge, automatically; /idd-plan with the flag --reconcile to repair or resync; /idd-publish for the publication row; only PROGRESS.md, never PRD.md; 2 checks first: the tracker gate with 80-word cells and no dates in cells, the PRD size and fold gates, which only report, manifest drift with no unlisted files, and line width of at most 100 characters; 3 one open batch PR: the branch progress/batch with docs(progress) commits; it stays open for review and each update adds a commit; two batches open means stop until there is one; 4 merged at a milestone: a slice validated or a release finished, before acceptance or before publishing, at the end of /idd-auto, or your own --reconcile; with changes requested or threads open it exits with code 2, awaiting review; a pre-push hook refuses direct pushes to the PRD's main, skipped if the clone has its own hooks
Progress: updates gather in one batch PR, merged at milestones

Auto. /idd-auto repeats plan, issue, implement and land until the PRD is done, then runs acceptance. A red check stops it.

Auto: you run /idd-auto with a project, once; 1 bind the target: the exact PRD and code pair, and a missing code repo is made, private; read the PRD, tracker and GitHub fresh at every turn; done means every requirement landed or validated, and also clean trees with no branch or batch left open; 2 one issue at a time: resume active work before starting new; /idd-plan, then /idd-issue for the one next issue; /idd-implement, which waits for checks and reviews; /idd-land to merge, close and reconcile; a dashed arrow loops back for the next issue; 3 then the whole product, when none are left: merge the tracker batch; /idd-acceptance, a required final gate; a product bug becomes one repair issue under the same slice, back into the loop; a new feature stops for your OK, and the PRD changes first; 4 stops, never bends: a red check, a conflict or an open choice becomes one precise blocker; if you can clear it, one question, then resume; it never publishes, promotes or accepts residuals; no trace file, each turn reads GitHub and the PRD again; finishing ends its authority, and a later request needs its own go-ahead
Auto: one issue at a time until the PRD is done, then acceptance

Acceptance. /idd-acceptance tests the finished product the way people reach it: browser, API, CLI or container.

Acceptance: in comes a finished pair, every issue landed, trees clean; 1 bind: the exact pair, all landed, no open issue, PR or branch; a tracker batch still open means stop and reconcile it first; PRD outcomes become journeys, plus whole-product checks; unit tests alone are never the final boundary; 2 the real boundary: a browser through Playwright, by role and label; an HTTP service as its real process with real dependencies; a CLI or library in a fresh setup with pinned output; a container, worker or migration, waiting for health, with throwaway state; 3 run it: a clean or seeded start, waiting for readiness with no fixed sleeps; every journey, a bad path, and a restart when it matters; preserved artifacts exist and match their row; always tear down, even after a failure; 4 PASS, or FAIL by kind: a product bug becomes one normal repair issue; bad fixture or data is fixed and run again; an unclear spec stops and asks for a clear contract; an environment problem is reported as the exact blocker; it never deploys, merges, edits the PRD or weakens a test
Acceptance: the whole product tested where people use it, failures sorted by kind

Publish. /idd-publish scans the whole history for secrets and private names, then makes only the code repo public.

Publishing: you run /idd-publish with a project, explicitly; 1 prepare, still private: reconcile the tracker at this pre-publish milestone; one preparation issue through plan, issue, implement and land; a license, MIT by default, green tests and an end-to-end check; the preparation change is scanned before it is pushed; 2 scan every commit: every commit message and every file on every ref; old PR refs too, since GitHub keeps them; secrets and private names from a built-in list plus your terms; a hit in a commit message can't be purged, so it takes a new repo, or you accept it knowingly; 3 check by hand: issues, comments, reviews and their edit history; Actions runs, logs and artifacts; branches, tags, releases, metadata, and package and doc links; any match blocks the visibility change; 4 flip and verify: the code repo becomes public and the PRD repo stays private; a signed-out check finds the code readable and the PRD denied; re-applied protection means the rulesets are now enforced; publishing is not deploying: no hosting, release or package
Publishing: prepare while private, scan everything, then make only the code public

Evolve. /idd-evolve changes the method only for proven lessons, through a reviewed PR. Rejected ideas leave no trace.

Evolving: in comes evidence from real runs, or a simplify pass; 1 evidence: post-plan, issue order and tracker accuracy; post-create, how an issue was written; post-issue, one issue's diff, checks and PR; simplify, merge, compress and delete; 2 the gate is the constitution: proven and high value, not already covered; smaller than the friction, delete before adding; past issues the same or better, naming the one it could hurt; size caps of 60 to 160 lines per skill file; 3 pass: the smallest edit with validate.sh passing; propose.sh opens a PR on evolve/<slug> and never writes main; the maintainer reviews, and land-evolution.sh merges on their word; skills linked to the checkout keep serving main until it lands; 4 fail: nothing happens, no log and no queue, and git history is the only record; new features don't come this way, they go through the PRD and an issue; one reproduced defect is proof enough, advice on behaviour needs several runs
Evolving: proven lessons go through a reviewed PR; the rest leaves nothing

来源Source: github.com

← 全部架构← All architectures