[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CHR5RZFJ1TTCRNRJQ4KABC":3,"skill-same:01M6CHR5RZFJ1TTCRNRJQ4KABC":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6CHR5RZFJ1TTCRNRJQ4KABC","epic-composer",null,"Group follow-up items into vertical epics with prioritized sub-issues and a blocker DAG. Get sign-off on the full set. Write ASD-STE100 bodies with ASCII diagrams. Post to GitHub with sub-issues, blocked-by links, and existing labels. Mirror into Pasture tasks only if the project tracks work with Pasture. Use when deferred items or review findings must become an approved set of epics and issues.","dayvidpham\u002Faura-plugins","dayvidpham","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F22456875?v=4","01M6CHR0F6J2M4QEHFR85XRNSR","David Huu Pham","01M6CHR0KQJ4DK5KSZ9TRTP7DW",2,"MIT","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fepic-composer\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"composer","EPIC","epic composer","when","review","labels","Existing","mirror","tracks","links","review findings","ascii","get","project","diagrams","up","only","use","write","work","SET","issues","tasks","dag","github","2026-11-10 10:12:30",false,"---\nname: epic-composer\ndescription: Group follow-up items into vertical epics with prioritized sub-issues and a blocker DAG. Get sign-off on the full set. Write ASD-STE100 bodies with ASCII diagrams. Post to GitHub with sub-issues, blocked-by links, and existing labels. Mirror into Pasture tasks only if the project tracks work with Pasture. Use when deferred items or review findings must become an approved set of epics and issues.\n---\n\n# Compose, approve, and post epics with their sub-issues\n\nTurn a loose set of follow-up items into vertical epics. Give each epic prioritized sub-issues\nand a blocker DAG. Get approval for the full set before you create anything. Then create the\nissues, create the epics, wire the relations, and apply labels. Mirror into Pasture tasks when\nthe project tracks work with Pasture.\n\nPasture tracking is optional. Use the Pasture steps only when the project tracks work with\n`pasture task` and has a recorded namespace. Without Pasture, GitHub is the only record. Collect\ninputs from issues, PR review threads, and notes. Skip every `pasture task` command when the\nproject does not use Pasture. Keep the rest unchanged.\n\nBefore tracker recipes, select the intended store and explicit repository\nnamespace, and verify the current author with `pasture task agents list` \u002F `show`.\nFor this repository, bind `PASTURE_NAMESPACE` to\n`https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins`; machine comments use the already\nregistered `pasture-system--00000000-0000-0000-0000-000000000000` actor as\n`PASTURE_AUTHOR`. Human comments use their actual registered identity. Do not\nauto-register, guess an author or use legacy short IDs. Bind every task variable\nfrom a verified full URI; on creation capture the returned JSON `id` immediately\n(positional title, separate label commands). Retry failed post-create steps with\nthe retained URI, never by recreating the task. Other repos use their own recorded\nnamespace, not Aura's namespace.\n\n## Preconditions\n\n- `gh auth status` succeeds. You can reach each target repository with `-R \u003Cowner>\u002F\u003Crepo>`.\n- The user has named the batch of items. Examples: a deferred list, a follow-up ledger, review\n  findings.\n- You know the primary repository for each epic.\n\nStop and ask if authentication, repository access, or the required GitHub permissions are not\navailable.\n\n## Workflow\n\n1. **Inspect**\n   - Read each repository's `AGENTS.md`. Read the code the items touch.\n   - Collect every candidate item before you group. Sources: user-deferred items, review findings\n     routed to follow-ups, observations recorded during verification.\n   - For each item record four facts: the source (issue number, PR thread, or Pasture task URI), the\n     repo, one line of substance, and whether a GitHub issue exists.\n     ```sh\n     pasture task list --namespace \"$PASTURE_NAMESPACE\" --format json \\\n       | jq -r '.[] | select(.status!=\"closed\") | \"\\(.id) | \\(.title)\"'\n     pasture task show \"$TASK_URI\" --namespace \"$PASTURE_NAMESPACE\" \\\n       | grep -oE 'https:\u002F\u002Fgithub.com\u002F[^ )]+\u002Fissues\u002F[0-9]+'   # empty = no issue yet\n     ```\n   - Search for existing epics and duplicates in every repo. Search the tracker too, if used.\n     ```sh\n     gh issue list -R \u003Cowner>\u002F\u003Crepo> --label epic --state open --limit 50 --json number,title\n     gh issue list -R \u003Cowner>\u002F\u003Crepo> --state open --limit 100 --search \"\u003Ckey terms> in:title,body\"\n     pasture task list --namespace \"$PASTURE_NAMESPACE\" --type epic --format json \\\n       | jq -r '.[] | select(.status!=\"closed\") | \"\\(.id) | \\(.priority) | \\(.title)\"'\n     ```\n   - Read the bodies of the adjacent epics. Decide per item: a new epic, or re-home the item into\n     an existing epic. Do not create an epic that already exists. Do not duplicate an open issue.\n\n2. **Draft the structure**\n   - Group vertically. An epic is one concern a user or operator can name. Examples: \"origin\n     coverage gaps\", \"test-infrastructure hardening\". Group by the concern the items change. Do\n     not group by repo. Do not group by who found the item. A cleanup-only group is allowed at\n     the lowest priority.\n   - Prioritize the epic and every item. Scale: P0 blocks users now. P1 is next. P2 is planned.\n     P3 is when convenient. The epic's priority equals its highest item. Inside an epic, the first\n     one or two items matter. The rest are improvements. Give one sentence of reason for each\n     call that is not obvious.\n   - Order into a DAG. For every pair of items ask: must one finish before the other is correct\n     or cheap? Typical arrows: a decision before the work it scopes. A shared helper before its\n     callers. A producer-side change before a consumer re-run. A data-integrity fix before a count\n     that depends on it. Items with no arrow are independent. Say so.\n   - Titles: epics `[P1][Epic] \u003Ctitle>`. Issues `[P2] \u003Ctitle>`.\n\n3. **Refine and approve the structure**\n   - Present one context message in ASD-STE100 with an ASCII diagram. Include: the epics, every\n     sub-issue with its priority, the DAG with arrows, the re-homing table (existing epic \u003C-\n     items), and which items become new issues and which are retitled. End the turn.\n   - In the next turn, ask for corrections or explicit approval with AskUserQuestion.\n   - Apply the refinements. Present again when a material detail changes. Examples: a new\n     grouping, a moved item, a changed priority, a new arrow.\n   - Do not write bodies for posting before the structure is approved.\n\n4. **Draft the bodies**\n   - Language rules (hard):\n     - ASD-STE100. Short sentences. Active voice. One idea per sentence. Imperative steps. Plain\n       words. No em-dashes.\n     - Use industry-standard names: fail-safe default, schema migration, backfill, closed enum,\n       CHECK constraint, trust boundary, discovery scope vs access control, fixture, golden test,\n       mutation testing, build tag, REST endpoint, WebSocket topic, OpenAPI contract, evidence,\n       provenance.\n     - Reuse the codebase's concept vocabulary. The identifiers do not have to match. Grep before\n       you name a concept. Keep one shared glossary across all bodies, so the set reads as one\n       system.\n     - Write cross-repo references as `owner\u002Frepo#N`. Example: `acme\u002Fschema#82`. GitHub links\n       only that form. A bare `schema#82` never links. Same-repo references stay `#N`.\n     - Do not put internal task taxonomy in bodies. No Pasture task URIs. No slice, wave, or proposal\n       names. No reviewer axis names. Refer to work by substance and by issue numbers.\n   - Epic body sections: Why. Concept map (an ASCII diagram of the API surfaces, the\n     infrastructure pieces, and the child issues placed on that map). Children table (priority,\n     title, blocked by). Definition of done. Related epics.\n   - Issue body sections: Problem (grounded with file paths and measured numbers). Scope (what\n     changes and what does not). Acceptance (observable outcomes, fixtures named). Diagram.\n     Blocked by \u002F Blocks. Related.\n   - The issue diagram is narrow. It shows that issue's own change: the exact data flow, the\n     before and after, or the failure path. It must be more specific than the epic diagram. It is\n     never a rehash.\n   - Bodies written before the new issues exist use `NEW-\u003Ckey>` for their numbers.\n   - Delegate the writing to background agents. Give each agent an explicit cheap model. Do not\n     use the session's top model unless the user names it. Use one shared brief file, one shared\n     glossary file, and one draft file per body.\n   - Review every draft. Run the language rules as a checklist. Grep for internal taxonomy, bare\n     cross-repo references, and em-dashes. Read at least one epic, one new issue, and one\n     addendum in full.\n\n5. **Refine and approve the bodies**\n   - Present the drafts to the user. Give the paths. Show the epic bodies inline when they are\n     short.\n   - Ask for corrections or explicit approval. Apply the refinements. Present again when a\n     material detail changes.\n   - Do not create anything before the user approves the current drafts. Keep the approved\n     scope. If you find an ambiguity after approval, refine and get approval again before you\n     change a body.\n\n6. **Create**\n   - Order: new issues first. Then substitute placeholders. Then existing-issue addenda. Then\n     epics. Then relations. Then labels.\n   - Markdown through a shell (hard rule): never pass a body inside a double-quoted argument.\n     The shell expands or eats backticks, `$`, `!`, and glob characters. The posted body then\n     loses its code spans. Use one of two safe forms.\n     1. A file, written with a quoted heredoc, passed with `--body-file`. Best for long bodies.\n     2. A single-quoted argument. Plain `'...'` disables all expansion. The only character you\n        cannot write inside it is `'` itself. ANSI-C quoting `$'...'` also works. It lets you\n        write `\\'` for a quote and `\\n` for a newline. It interprets every other backslash\n        sequence, so keep diagrams out of it.\n     ```sh\n     # form 1: a file for anything long or containing a single quote\n     cat > body.md \u003C\u003C'BODY'\n     ## Problem\n     The `session_origin` column ...\n     BODY\n     gh issue create -R \u003Co>\u002F\u003Cr> --title '[P2] \u003Ctitle>' --body-file body.md\n     # form 2: single quotes, no expansion at all\n     gh issue comment \u003Cn> -R \u003Co>\u002F\u003Cr> --body 'Run `make check`. The `$HOME` path is not expanded.'\n     ```\n   - Placeholders. After you create the new issues, substitute every `NEW-\u003Ckey>` in every draft.\n     Same repo becomes `#N`. Other repo becomes `owner\u002Frepo#N`. Re-post the new issues whose\n     bodies held placeholders. Grep all drafts for `NEW-` before you post the epics.\n   - Existing issue: retitle it and append the addendum. Build a merged file. Never splice inline.\n     ```sh\n     { gh issue view \u003Cn> -R \u003Co>\u002F\u003Cr> --json body --jq .body; printf '\\n\\n'; cat addendum.md; } > merged.md\n     gh issue edit \u003Cn> -R \u003Co>\u002F\u003Cr> --title '[P3] \u003Ctitle>' --body-file merged.md\n     ```\n   - Epic: `gh issue create -R \u003Co>\u002F\u003Cr> --title '[P2][Epic] \u003Ctitle>' --body-file epic.md --label epic`.\n   - Relations. Sub-issues and blocked-by both work across repositories within one owner.\n     Verified 2026-08-26: `peasant-labs\u002Fschema#82` is a sub-issue of a peasant epic, and\n     `peasant-labs\u002Fvillage#48` is blocked by `peasant-labs\u002Fpeasant#193`. State each cross-repo\n     relation in the body too, so it reads without the sidebar.\n     ```sh\n     CHILD_ID=$(gh api repos\u002F\u003Co>\u002F\u003Cr>\u002Fissues\u002F\u003Cchild> --jq .id)\n     gh api -X POST repos\u002F\u003Co>\u002F\u003Cepic-repo>\u002Fissues\u002F\u003Cepic>\u002Fsub_issues -F sub_issue_id=$CHILD_ID\n     EARLIER_ID=$(gh api repos\u002F\u003Co>\u002F\u003Cr>\u002Fissues\u002F\u003Cearlier> --jq .id)\n     gh api -X POST repos\u002F\u003Co>\u002F\u003Cr>\u002Fissues\u002F\u003Clater>\u002Fdependencies\u002Fblocked_by -F issue_id=$EARLIER_ID\n     ```\n   - Read every posted body back with `gh issue view \u003Cn> --json body --jq .body`. Check that\n     every code span and diagram survived. A missing backtick or a collapsed `$var` is a posting\n     defect. Repost from the file.\n\n7. **Label**\n   - List each repo's labels first: `gh label list -R \u003Co>\u002F\u003Cr> --json name,description`.\n   - Give every sub-issue one or two labels from the existing inventory. Choose by substance.\n     `bug`: shipped behaviour is wrong. `enhancement`: new or better behaviour. `documentation`:\n     comments or docs only. `question`: a decision to make. A component label (example:\n     `tui-kit`): the repo has one and the change touches that component. `good first issue`: only\n     for small, self-contained changes. Epics carry `epic`.\n   - Apply with `gh issue edit \u003Cn> -R \u003Co>\u002F\u003Cr> --add-label '\u003Clabel>'`. The writer of a body labels\n     it. The orchestrator checks the mapping against the inventory.\n   - If a needed label does not exist, raise it to the user. Give the proposed name and\n     description. Wait for the answer. Do the same if you only consider creating a label. Do not\n     create a label on your own.\n\n8. **Mirror in Pasture (only if the project tracks work with Pasture)**\n   - Create one Pasture epic per GitHub epic. Use the same title and the same priority.\n   - Chain `pasture task dep add \"$EPIC_URI\" --blocked-by \"$ITEM_URI\"` for every child. Chain\n     `pasture task dep add \"$LATER_URI\" --blocked-by \"$EARLIER_URI\"` for every arrow. Set each\n     item's priority. Use full task URIs and the explicit namespace.\n   - Record each issue URL on its Pasture task with\n     `pasture task comment add \"$TASK_URI\" \"\u003Curl>\" --author \"$PASTURE_AUTHOR\" --namespace \"$PASTURE_NAMESPACE\"`.\n   - Leave the user-deferred ledger epic open and untouched.\n\n9. **Report**\n   - Send one message. Include: the epics with numbers and priorities, the DAG with numbers, the\n     re-homings, the label mapping, and the count of issues created versus retitled. Then stop.\n\n## Hard rules\n\n1. Do not create an epic or an issue before the user approves the current structure (step 3) and\n   the current bodies (step 5).\n2. Do not create an epic that already exists. Do not duplicate an open issue. Re-home instead.\n3. Keep the approved scope. If you find an ambiguity after approval, refine and get approval\n   again before you change anything.\n4. Every epic and every item carries a priority in its title. Every arrow in the DAG becomes a\n   native blocked-by relation. State the arrow in the body too.\n5. Pass bodies through a file or a single-quoted argument. Never use a double-quoted argument.\n   Read every posted body back.\n6. Write cross-repo references as `owner\u002Frepo#N`. Put no internal task taxonomy in any body.\n7. Take labels from the existing inventory. A new label is a question for the user. Never create\n   one on your own.\n8. Pasture tracking is optional. When used, the mirror carries the same priorities and arrows as GitHub.\n","# Compose, approve, and post epics with their sub-issues\n\nTurn a loose set of follow-up items into vertical epics. Give each epic prioritized sub-issues\nand a blocker DAG. Get approval for the full set before you create anything. Then create the\nissues, create the epics, wire the relations, and apply labels. Mirror into Pasture tasks when\nthe project tracks work with Pasture.\n\nPasture tracking is optional. Use the Pasture steps only when the project tracks work with\n`pasture task` and has a recorded namespace. Without Pasture, GitHub is the only record. Collect\ninputs from issues, PR review threads, and notes. Skip every `pasture task` command when the\nproject does not use Pasture. Keep the rest unchanged.\n\nBefore tracker recipes, select the intended store and explicit repository\nnamespace, and verify the current author with `pasture task agents list` \u002F `show`.\nFor this repository, bind `PASTURE_NAMESPACE` to\n`https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins`; machine comments use the already\nregistered `pasture-system--00000000-0000-0000-0000-000000000000` actor as\n`PASTURE_AUTHOR`. Human comments use their actual registered identity. Do not\nauto-register, guess an author or use legacy short IDs. Bind every task variable\nfrom a verified full URI; on creation capture the returned JSON `id` immediately\n(positional title, separate label commands). Retry failed post-create steps with\nthe retained URI, never by recreating the task. Other repos use their own recorded\nnamespace, not Aura's namespace.\n\n## Preconditions\n\n- `gh auth status` succeeds. You can reach each target repository with `-R \u003Cowner>\u002F\u003Crepo>`.\n- The user has named the batch of items. Examples: a deferred list, a follow-up ledger, review\n  findings.\n- You know the primary repository for each epic.\n\nStop and ask if authentication, repository access, or the required GitHub permissions are not\navailable.\n\n## Workflow\n\n1. **Inspect**\n   - Read each repository's `AGENTS.md`. Read the code the items touch.\n   - Collect every candidate item before you group. Sources: user-deferred items, review findings\n     routed to follow-ups, observations recorded during verification.\n   - For each item record four facts: the source (issue number, PR thread, or Pasture task URI), the\n     repo, one line of substance, and whether a GitHub issue exists.\n     ```sh\n     pasture task list --namespace \"$PASTURE_NAMESPACE\" --format json \\\n       | jq -r '.[] | select(.status!=\"closed\") | \"\\(.id) | \\(.title)\"'\n     pasture task show \"$TASK_URI\" --namespace \"$PASTURE_NAMESPACE\" \\\n       | grep -oE 'https:\u002F\u002Fgithub.com\u002F[^ )]+\u002Fissues\u002F[0-9]+'   # empty = no issue yet\n     ```\n   - Search for existing epics and duplicates in every repo. Search the tracker too, if used.\n     ```sh\n     gh issue list -R \u003Cowner>\u002F\u003Crepo> --label epic --state open --limit 50 --json number,title\n     gh issue list -R \u003Cowner>\u002F\u003Crepo> --state open --limit 100 --search \"\u003Ckey terms> in:title,body\"\n     pasture task list --namespace \"$PASTURE_NAMESPACE\" --type epic --format json \\\n       | jq -r '.[] | select(.status!=\"closed\") | \"\\(.id) | \\(.priority) | \\(.title)\"'\n     ```\n   - Read the bodies of the adjacent epics. Decide per item: a new epic, or re-home the item into\n     an existing epic. Do not create an epic that already exists. Do not duplicate an open issue.\n\n2. **Draft the structure**\n   - Group vertically. An epic is one concern a user or operator can name. Examples: \"origin\n     coverage gaps\", \"test-infrastructure hardening\". Group by the concern the items change. Do\n     not group by repo. Do not group by who found the item. A cleanup-only group is allowed at\n     the lowest priority.\n   - Prioritize the epic and every item. Scale: P0 blocks users now. P1 is next. P2 is planned.\n     P3 is when convenient. The epic's priority equals its highest item. Inside an epic, the first\n     one or two items matter. The rest are improvements. Give one sentence of reason for each\n     call that is not obvious.\n   - Order into a DAG. For every pair of items ask: must one finish before the other is correct\n     or cheap? Typical arrows: a decision before the work it scopes. A shared helper before its\n     callers. A producer-side change before a consumer re-run. A data-integrity fix before a count\n     that depends on it. Items with no arrow are independent. Say so.\n   - Titles: epics `[P1][Epic] \u003Ctitle>`. Issues `[P2] \u003Ctitle>`.\n\n3. **Refine and approve the structure**\n   - Present one context message in ASD-STE100 with an ASCII diagram. Include: the epics, every\n     sub-issue with its priority, the DAG with arrows, the re-homing table (existing epic \u003C-\n     items), and which items become new issues and which are retitled. End the turn.\n   - In the next turn, ask for corrections or explicit approval with AskUserQuestion.\n   - Apply the refinements. Present again when a material detail changes. Examples: a new\n     grouping, a moved item, a changed priority, a new arrow.\n   - Do not write bodies for posting before the structure is approved.\n\n4. **Draft the bodies**\n   - Language rules (hard):\n     - ASD-STE100. Short sentences. Active voice. One idea per sentence. Imperative steps. Plain\n       words. No em-dashes.\n     - Use industry-standard names: fail-safe default, schema migration, backfill, closed enum,\n       CHECK constraint, trust boundary, discovery scope vs access control, fixture, golden test,\n       mutation testing, build tag, REST endpoint, WebSocket topic, OpenAPI contract, evidence,\n       provenance.\n     - Reuse the codebase's concept vocabulary. The identifiers do not have to match. Grep before\n       you name a concept. Keep one shared glossary across all bodies, so the set reads as one\n       system.\n     - Write cross-repo references as `owner\u002Frepo#N`. Example: `acme\u002Fschema#82`. GitHub links\n       only that form. A bare `schema#82` never links. Same-repo references stay `#N`.\n     - Do not put internal task taxonomy in bodies. No Pasture task URIs. No slice, wave, or proposal\n       names. No reviewer axis names. Refer to work by substance and by issue numbers.\n   - Epic body sections: Why. Concept map (an ASCII diagram of the API surfaces, the\n     infrastructure pieces, and the child issues placed on that map). Children table (priority,\n     title, blocked by). Definition of done. Related epics.\n   - Issue body sections: Problem (grounded with file paths and measured numbers). Scope (what\n     changes and what does not). Acceptance (observable outcomes, fixtures named). Diagram.\n     Blocked by \u002F Blocks. Related.\n   - The issue diagram is narrow. It shows that issue's own change: the exact data flow, the\n     before and after, or the failure path. It must be more specific than the epic diagram. It is\n     never a rehash.\n   - Bodies written before the new issues exist use `NEW-\u003Ckey>` for their numbers.\n   - Delegate the writing to background agents. Give each agent an explicit cheap model. Do not\n     use the session's top model unless the user names it. Use one shared brief file, one shared\n     glossary file, and one draft file per body.\n   - Review every draft. Run the language rules as a checklist. Grep for internal taxonomy, bare\n     cross-repo references, and em-dashes. Read at least one epic, one new issue, and one\n     addendum in full.\n\n5. **Refine and approve the bodies**\n   - Present the drafts to the user. Give the paths. Show the epic bodies inline when they are\n     short.\n   - Ask for corrections or explicit approval. Apply the refinements. Present again when a\n     material detail changes.\n   - Do not create anything before the user approves the current drafts. Keep the approved\n     scope. If you find an ambiguity after approval, refine and get approval again before you\n     change a body.\n\n6. **Create**\n   - Order: new issues first. Then substitute placeholders. Then existing-issue addenda. Then\n     epics. Then relations. Then labels.\n   - Markdown through a shell (hard rule): never pass a body inside a double-quoted argument.\n     The shell expands or eats backticks, `$`, `!`, and glob characters. The posted body then\n     loses its code spans. Use one of two safe forms.\n     1. A file, written with a quoted heredoc, passed with `--body-file`. Best for long bodies.\n     2. A single-quoted argument. Plain `'...'` disables all expansion. The only character you\n        cannot write inside it is `'` itself. ANSI-C quoting `$'...'` also works. It lets you\n        write `\\'` for a quote and `\\n` for a newline. It interprets every other backslash\n        sequence, so keep diagrams out of it.\n     ```sh\n     # form 1: a file for anything long or containing a single quote\n     cat > body.md \u003C\u003C'BODY'\n     ## Problem\n     The `session_origin` column ...\n     BODY\n     gh issue create -R \u003Co>\u002F\u003Cr> --title '[P2] \u003Ctitle>' --body-file body.md\n     # form 2: single quotes, no expansion at all\n     gh issue comment \u003Cn> -R \u003Co>\u002F\u003Cr> --body 'Run `make check`. The `$HOME` path is not expanded.'\n     ```\n   - Placeholders. After you create the new issues, substitute every `NEW-\u003Ckey>` in every draft.\n     Same repo becomes `#N`. Other repo becomes `owner\u002Frepo#N`. Re-post the new issues whose\n     bodies held placeholders. Grep all drafts for `NEW-` before you post the epics.\n   - Existing issue: retitle it and append the addendum. Build a merged file. Never splice inline.\n     ```sh\n     { gh issue view \u003Cn> -R \u003Co>\u002F\u003Cr> --json body --jq .body; printf '\\n\\n'; cat addendum.md; } > merged.md\n     gh issue edit \u003Cn> -R \u003Co>\u002F\u003Cr> --title '[P3] \u003Ctitle>' --body-file merged.md\n     ```\n   - Epic: `gh issue create -R \u003Co>\u002F\u003Cr> --title '[P2][Epic] \u003Ctitle>' --body-file epic.md --label epic`.\n   - Relations. Sub-issues and blocked-by both work across repositories within one owner.\n     Verified 2026-08-26: `peasant-labs\u002Fschema#82` is a sub-issue of a peasant epic, and\n     `peasant-labs\u002Fvillage#48` is blocked by `peasant-labs\u002Fpeasant#193`. State each cross-repo\n     relation in the body too, so it reads without the sidebar.\n     ```sh\n     CHILD_ID=$(gh api repos\u002F\u003Co>\u002F\u003Cr>\u002Fissues\u002F\u003Cchild> --jq .id)\n     gh api -X POST repos\u002F\u003Co>\u002F\u003Cepic-repo>\u002Fissues\u002F\u003Cepic>\u002Fsub_issues -F sub_issue_id=$CHILD_ID\n     EARLIER_ID=$(gh api repos\u002F\u003Co>\u002F\u003Cr>\u002Fissues\u002F\u003Cearlier> --jq .id)\n     gh api -X POST repos\u002F\u003Co>\u002F\u003Cr>\u002Fissues\u002F\u003Clater>\u002Fdependencies\u002Fblocked_by -F issue_id=$EARLIER_ID\n     ```\n   - Read every posted body back with `gh issue view \u003Cn> --json body --jq .body`. Check that\n     every code span and diagram survived. A missing backtick or a collapsed `$var` is a posting\n     defect. Repost from the file.\n\n7. **Label**\n   - List each repo's labels first: `gh label list -R \u003Co>\u002F\u003Cr> --json name,description`.\n   - Give every sub-issue one or two labels from the existing inventory. Choose by substance.\n     `bug`: shipped behaviour is wrong. `enhancement`: new or better behaviour. `documentation`:\n     comments or docs only. `question`: a decision to make. A component label (example:\n     `tui-kit`): the repo has one and the change touches that component. `good first issue`: only\n     for small, self-contained changes. Epics carry `epic`.\n   - Apply with `gh issue edit \u003Cn> -R \u003Co>\u002F\u003Cr> --add-label '\u003Clabel>'`. The writer of a body labels\n     it. The orchestrator checks the mapping against the inventory.\n   - If a needed label does not exist, raise it to the user. Give the proposed name and\n     description. Wait for the answer. Do the same if you only consider creating a label. Do not\n     create a label on your own.\n\n8. **Mirror in Pasture (only if the project tracks work with Pasture)**\n   - Create one Pasture epic per GitHub epic. Use the same title and the same priority.\n   - Chain `pasture task dep add \"$EPIC_URI\" --blocked-by \"$ITEM_URI\"` for every child. Chain\n     `pasture task dep add \"$LATER_URI\" --blocked-by \"$EARLIER_URI\"` for every arrow. Set each\n     item's priority. Use full task URIs and the explicit namespace.\n   - Record each issue URL on its Pasture task with\n     `pasture task comment add \"$TASK_URI\" \"\u003Curl>\" --author \"$PASTURE_AUTHOR\" --namespace \"$PASTURE_NAMESPACE\"`.\n   - Leave the user-deferred ledger epic open and untouched.\n\n9. **Report**\n   - Send one message. Include: the epics with numbers and priorities, the DAG with numbers, the\n     re-homings, the label mapping, and the count of issues created versus retitled. Then stop.\n\n## Hard rules\n\n1. Do not create an epic or an issue before the user approves the current structure (step 3) and\n   the current bodies (step 5).\n2. Do not create an epic that already exists. Do not duplicate an open issue. Re-home instead.\n3. Keep the approved scope. If you find an ambiguity after approval, refine and get approval\n   again before you change anything.\n4. Every epic and every item carries a priority in its title. Every arrow in the DAG becomes a\n   native blocked-by relation. State the arrow in the body too.\n5. Pass bodies through a file or a single-quoted argument. Never use a double-quoted argument.\n   Read every posted body back.\n6. Write cross-repo references as `owner\u002Frepo#N`. Put no internal task taxonomy in any body.\n7. Take labels from the existing inventory. A new label is a question for the user. Never create\n   one on your own.\n8. Pasture tracking is optional. When used, the mirror carries the same priorities and arrows as GitHub.\n",{"name":5,"description":7},"main","7fe8098d35c17a7d6497a81e4c08abb4c2d02735",".claude\u002Fskills\u002Fepic-composer",0,"https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins","https:\u002F\u002Fgithub.com\u002Fdayvidpham","dhpham.com","2026-11-11 16:48:56",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add dayvidpham\u002Faura-plugins --skill epic-composer",{"tool":63,"command":64},"bunx","bunx skills add dayvidpham\u002Faura-plugins --skill epic-composer",{"tool":66,"command":67},"pnpm","pnpm dlx skills add dayvidpham\u002Faura-plugins --skill epic-composer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fepic-composer\u002FSKILL.md",true,[71,77],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"graphviz-conventions.dot","OTHER","其他",5970,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-community-writing-skills\u002Fgraphviz-conventions.dot",{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"persuasion-principles.md","REFERENCE","参考文档",5908,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-community-writing-skills\u002Fpersuasion-principles.md",[84,109,137,142,148,153],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":44},"01M70PPVS3CW9RYWGZ4KSNV7MV","afk-implement","Run an unattended (\"AFK\") implementation session as the supervisor — scope small progressive iterations, push feature branches, open pull requests, drive review waves to clean, and never merge. Use when the user says they are going AFK or to bed, asks for overnight autonomous implementation, says \"don't block on me\", \"open PRs but don't merge\", \"progressive adoption\", or \"stack changes\".","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fafk-implement\u002FSKILL.md",[],[91,92,93,94,95,96,97,98,99,100,22,23,101,102,103,104,105,106,107,108],"implement","afk implement","pull","bed","never","scope","clean","branches","open","autonomous","pull requests","stack","me","run","merge","unattended","overnight","but",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":120,"publishedAt":44},"01M6CHSCKDTSV05385SJ05XWW6","protocol","Aura protocol reference documentation — 12-phase workflow, agent roles, constraints, and coding standards. Read when you need to understand the full workflow or look up conventions.","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fskills\u002Fprotocol\u002FSKILL.md",[115],{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[111,121,122,123,124,34,125,126,127,128,129,130,22,131,132,133,134,135,136],"coding","standards","documentation","read","coding standards","reference","look","workflow","full","constraints","you","phase","roles","understand","conventions","aura",{"skillNo":138,"name":111,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":141,"publishedAt":44},"01M6CHSBJDVKGWAJWQCNQ22F9F","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002Fskills\u002Fprotocol\u002FSKILL.md",[],[111],{"skillNo":143,"name":144,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":44},"01M6CHSAJY85M0W8NEAN4PRF82","example","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002Fskills\u002Fexample\u002FSKILL.md",[],[144],{"skillNo":149,"name":144,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":44},"01M6CHS9KQJYCWR1C9F2GJDZYX","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002F.opencode\u002Fskill\u002Fexample\u002FSKILL.md",[],[144],{"skillNo":154,"name":144,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":44},"01M6CHS8MSW2SDQ5Y05A3GZES4","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Faura-plugins\u002Fblob\u002Fmain\u002Fnix\u002Fhm-module-test-data\u002Ffull\u002F.agents\u002Fskills\u002Fexample\u002FSKILL.md",[],[144]]