[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NVRTYQ352ZEPPBKA2918NF":3,"skill-same:01M6NVRTYQ352ZEPPBKA2918NF":75},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":60,"install":61,"resources":74},"01M6NVRTYQ352ZEPPBKA2918NF","design-flow",null,"Run the full design-to-build workflow as a guided sequence. Orchestrates all designer skills in order, from grilling through review. Use when user wants to go through the complete design process, start a project from scratch, run the full flow, or mentions \"design flow\" or \"full workflow\".","mattonweb\u002Fai-assistant-foundry","mattonweb","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2309734?v=4","01M6NQYCY846TKYN2ZCRS71WQ7","Matt Johnson","01M6NQYD2NPAQEFVD8TW9W0SVX",1,"MIT","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fdesign-ux\u002Fjulianoczkowski\u002Fdesign-flow\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"design flow","flow","design","use","scratch","sequence","From Scratch","complete","as","full","project","build","process","designer","start","build workflow","run","workflow","go","review","2026-11-10 10:12:30",false,"---\nname: design-flow\ndescription: Run the full design-to-build workflow as a guided sequence. Orchestrates all designer skills in order, from grilling through review. Use when user wants to go through the complete design process, start a project from scratch, run the full flow, or mentions \"design flow\" or \"full workflow\".\n---\n\nThis skill orchestrates the full designer workflow by running each skill in sequence. You are a guide walking the designer through each phase. Do not rush. Each phase must be completed and confirmed before moving to the next.\n\n## Example prompts\n\n- \"Run the full design flow\"\n- \"Walk me through the complete process for a new project\"\n- \"Start from scratch and take me through everything\"\n- \"Design flow for a dashboard app\"\n\n## The Sequence\n\n```\n1. Grill Me          → Clarify thinking\n2. Design Brief      → Document intent\n3. Info Architecture  → Define structure\n4. Design Tokens     → Establish visual system\n5. Brief to Tasks    → Plan the build\n6. Frontend Design   → Build it\n—\n7. Design Review     → Run separately when ready\n```\n\n## Rules\n\n1. **At the start**, tell the designer what the full sequence looks like (phases 1-6, with review available separately) and ask if they want to skip any phases. Common skip patterns:\n   - Already have a clear idea → skip grill-me\n   - Single component, not a full page → skip information-architecture\n   - Existing project with tokens → skip design-tokens\n\n2. **Before each phase**, announce which phase you are entering and what it will produce. Example: \"Phase 2: Design Brief. I'll interview you about the project and produce a DESIGN_BRIEF.md file. Ready?\"\n\n3. **During each phase**, read the corresponding SKILL.md file and follow its full instructions. Do not summarize or abbreviate the skill. Run it properly.\n\n4. **After each phase**, summarize what was produced (the file name, the key decisions, any open questions) and ask: \"Ready to move to the next phase?\" Wait for confirmation.\n\n5. **Between phases**, check if the output from the previous phase changes anything about the next phase. For example, if the brief names a philosophy, mention that the tokens phase will use it.\n\n6. **The designer can stop at any point.** If they say \"that's enough for now,\" summarize where they are in the sequence and what the next phase would be when they return.\n\n## Phase Details\n\n### Phase 1: Grill Me\n\nRead the `grill-me` skill (grill-me\u002FSKILL.md) and follow its instructions.\n**Produces**: Shared understanding of the project. No file output.\n**Transition**: \"We've resolved the key decisions. Ready to capture this as a design brief?\"\n\n### Phase 2: Design Brief\n\nRead the `design-brief` skill (design-brief\u002FSKILL.md) and follow its instructions.\n**Produces**: `.design\u002F\u003Cfeature-slug>\u002FDESIGN_BRIEF.md`.\n**Transition**: \"The brief is saved. Next is information architecture, where we'll define the page structure and navigation. Skip this if you're building a single component. Continue?\"\n\n### Phase 3: Information Architecture\n\nRead the `information-architecture` skill (information-architecture\u002FSKILL.md) and follow its instructions.\n**Produces**: `.design\u002F\u003Cfeature-slug>\u002FINFORMATION_ARCHITECTURE.md`.\n**Transition**: \"IA is defined. Next we'll generate design tokens (colors, spacing, typography) based on the philosophy from the brief. Continue?\"\n\n### Phase 4: Design Tokens\n\nRead the `design-tokens` skill (design-tokens\u002FSKILL.md) and follow its instructions.\n**Produces**: Token file (CSS variables, Tailwind config, or theme file depending on stack).\n**Transition**: \"Tokens are set. Next I'll break the brief into a task list so we can build in order. Continue?\"\n\n### Phase 5: Brief to Tasks\n\nRead the `brief-to-tasks` skill (brief-to-tasks\u002FSKILL.md) and follow its instructions.\n**Produces**: `.design\u002F\u003Cfeature-slug>\u002FTASKS.md`.\n**Transition**: \"Tasks are ready. Now we build. I'll start with the first task on the list. Continue?\"\n\n### Phase 6: Frontend Design\n\nRead the `frontend-design` skill (frontend-design\u002FSKILL.md) and follow its instructions.\nWork through the tasks from `TASKS.md` in order. After completing each task, check it off and confirm with the designer before moving to the next task.\n**Produces**: Built components and pages.\n**Transition**: \"The flow is complete. Your brief, IA, tokens, and tasks are all saved in the project. When you're ready for a design review, run `\u002Fdesign-review` and I'll critique the build against the brief.\"\n\n**The flow ends here.** Phase 7 is not automatic.\n\n### Phase 7: Design Review (on request only)\n\nThis phase does NOT run automatically. It only runs if:\n\n- The designer explicitly asks for a review during the flow\n- The designer runs `\u002Fdesign-review` separately after building\n\nThe review requires built code to examine. If no components or pages have been built yet, do not run this phase. Instead, remind the designer: \"Run `\u002Fdesign-review` once you have something built. It will check the output against the brief.\"\n\nWhen triggered, read the `design-review` skill (design-review\u002FSKILL.md) and follow its instructions. The review will capture screenshots of the running application using Playwright MCP (preferred), the Cursor IDE Browser (fallback), or by asking the user to provide them manually if no browser tool is available.\n\n**Produces**: `.design\u002F\u003Cfeature-slug>\u002FDESIGN_REVIEW.md` + screenshots saved in `.design\u002F\u003Cfeature-slug>\u002Fscreenshots\u002F`.\n**Transition**: \"Review is done. Screenshots are saved in `.design\u002F\u003Cfeature-slug>\u002Fscreenshots\u002F`. If there are must-fix items, I can address them now.\"\n\n## Project Files Structure\n\nAll design flow artifacts are saved under `.design\u002F\u003Cfeature-slug>\u002F` where `\u003Cfeature-slug>` is a short, lowercase, hyphenated name derived from the feature being designed. This ensures multiple features can be designed independently without overwriting each other.\n\n```\n.design\u002F\n└── \u003Cfeature-slug>\u002F\n    ├── DESIGN_BRIEF.md              ← Phase 2: Project intent, goals, aesthetic direction\n    ├── INFORMATION_ARCHITECTURE.md  ← Phase 3: Navigation, page structure, user flows\n    ├── DESIGN_TOKENS.*              ← Phase 4: Colors, spacing, typography, shadows (CSS\u002FTailwind\u002Ftheme)\n    ├── TASKS.md                     ← Phase 5: Ordered build checklist from the brief\n    ├── DESIGN_REVIEW.md             ← Phase 7: Prioritized critique against the brief\n    └── screenshots\u002F                 ← Phase 7: Visual evidence from the running app\n        ├── review-[page]-desktop-1280.png\n        ├── review-[page]-tablet-768.png\n        ├── review-[page]-mobile-375.png\n        ├── review-[page]-dark-mode-*.png\n        └── review-[component]-[state].png\n```\n\nThe `screenshots\u002F` subfolder is created during the design review phase. All visual evidence of the review (responsive breakpoints, interactive states, dark mode) is saved here with descriptive filenames so findings in `DESIGN_REVIEW.md` are traceable.\n\n## If the Designer Returns Mid-Flow\n\nCheck the `.design\u002F` folder for existing feature subfolders. If files from earlier phases exist (DESIGN_BRIEF.md, INFORMATION_ARCHITECTURE.md, TASKS.md) inside a feature folder, read them to understand where the designer left off. Ask which feature to resume if multiple folders exist. Resume from the next incomplete phase.\n","This skill orchestrates the full designer workflow by running each skill in sequence. You are a guide walking the designer through each phase. Do not rush. Each phase must be completed and confirmed before moving to the next.\n\n## Example prompts\n\n- \"Run the full design flow\"\n- \"Walk me through the complete process for a new project\"\n- \"Start from scratch and take me through everything\"\n- \"Design flow for a dashboard app\"\n\n## The Sequence\n\n```\n1. Grill Me          → Clarify thinking\n2. Design Brief      → Document intent\n3. Info Architecture  → Define structure\n4. Design Tokens     → Establish visual system\n5. Brief to Tasks    → Plan the build\n6. Frontend Design   → Build it\n—\n7. Design Review     → Run separately when ready\n```\n\n## Rules\n\n1. **At the start**, tell the designer what the full sequence looks like (phases 1-6, with review available separately) and ask if they want to skip any phases. Common skip patterns:\n   - Already have a clear idea → skip grill-me\n   - Single component, not a full page → skip information-architecture\n   - Existing project with tokens → skip design-tokens\n\n2. **Before each phase**, announce which phase you are entering and what it will produce. Example: \"Phase 2: Design Brief. I'll interview you about the project and produce a DESIGN_BRIEF.md file. Ready?\"\n\n3. **During each phase**, read the corresponding SKILL.md file and follow its full instructions. Do not summarize or abbreviate the skill. Run it properly.\n\n4. **After each phase**, summarize what was produced (the file name, the key decisions, any open questions) and ask: \"Ready to move to the next phase?\" Wait for confirmation.\n\n5. **Between phases**, check if the output from the previous phase changes anything about the next phase. For example, if the brief names a philosophy, mention that the tokens phase will use it.\n\n6. **The designer can stop at any point.** If they say \"that's enough for now,\" summarize where they are in the sequence and what the next phase would be when they return.\n\n## Phase Details\n\n### Phase 1: Grill Me\n\nRead the `grill-me` skill (grill-me\u002FSKILL.md) and follow its instructions.\n**Produces**: Shared understanding of the project. No file output.\n**Transition**: \"We've resolved the key decisions. Ready to capture this as a design brief?\"\n\n### Phase 2: Design Brief\n\nRead the `design-brief` skill (design-brief\u002FSKILL.md) and follow its instructions.\n**Produces**: `.design\u002F\u003Cfeature-slug>\u002FDESIGN_BRIEF.md`.\n**Transition**: \"The brief is saved. Next is information architecture, where we'll define the page structure and navigation. Skip this if you're building a single component. Continue?\"\n\n### Phase 3: Information Architecture\n\nRead the `information-architecture` skill (information-architecture\u002FSKILL.md) and follow its instructions.\n**Produces**: `.design\u002F\u003Cfeature-slug>\u002FINFORMATION_ARCHITECTURE.md`.\n**Transition**: \"IA is defined. Next we'll generate design tokens (colors, spacing, typography) based on the philosophy from the brief. Continue?\"\n\n### Phase 4: Design Tokens\n\nRead the `design-tokens` skill (design-tokens\u002FSKILL.md) and follow its instructions.\n**Produces**: Token file (CSS variables, Tailwind config, or theme file depending on stack).\n**Transition**: \"Tokens are set. Next I'll break the brief into a task list so we can build in order. Continue?\"\n\n### Phase 5: Brief to Tasks\n\nRead the `brief-to-tasks` skill (brief-to-tasks\u002FSKILL.md) and follow its instructions.\n**Produces**: `.design\u002F\u003Cfeature-slug>\u002FTASKS.md`.\n**Transition**: \"Tasks are ready. Now we build. I'll start with the first task on the list. Continue?\"\n\n### Phase 6: Frontend Design\n\nRead the `frontend-design` skill (frontend-design\u002FSKILL.md) and follow its instructions.\nWork through the tasks from `TASKS.md` in order. After completing each task, check it off and confirm with the designer before moving to the next task.\n**Produces**: Built components and pages.\n**Transition**: \"The flow is complete. Your brief, IA, tokens, and tasks are all saved in the project. When you're ready for a design review, run `\u002Fdesign-review` and I'll critique the build against the brief.\"\n\n**The flow ends here.** Phase 7 is not automatic.\n\n### Phase 7: Design Review (on request only)\n\nThis phase does NOT run automatically. It only runs if:\n\n- The designer explicitly asks for a review during the flow\n- The designer runs `\u002Fdesign-review` separately after building\n\nThe review requires built code to examine. If no components or pages have been built yet, do not run this phase. Instead, remind the designer: \"Run `\u002Fdesign-review` once you have something built. It will check the output against the brief.\"\n\nWhen triggered, read the `design-review` skill (design-review\u002FSKILL.md) and follow its instructions. The review will capture screenshots of the running application using Playwright MCP (preferred), the Cursor IDE Browser (fallback), or by asking the user to provide them manually if no browser tool is available.\n\n**Produces**: `.design\u002F\u003Cfeature-slug>\u002FDESIGN_REVIEW.md` + screenshots saved in `.design\u002F\u003Cfeature-slug>\u002Fscreenshots\u002F`.\n**Transition**: \"Review is done. Screenshots are saved in `.design\u002F\u003Cfeature-slug>\u002Fscreenshots\u002F`. If there are must-fix items, I can address them now.\"\n\n## Project Files Structure\n\nAll design flow artifacts are saved under `.design\u002F\u003Cfeature-slug>\u002F` where `\u003Cfeature-slug>` is a short, lowercase, hyphenated name derived from the feature being designed. This ensures multiple features can be designed independently without overwriting each other.\n\n```\n.design\u002F\n└── \u003Cfeature-slug>\u002F\n    ├── DESIGN_BRIEF.md              ← Phase 2: Project intent, goals, aesthetic direction\n    ├── INFORMATION_ARCHITECTURE.md  ← Phase 3: Navigation, page structure, user flows\n    ├── DESIGN_TOKENS.*              ← Phase 4: Colors, spacing, typography, shadows (CSS\u002FTailwind\u002Ftheme)\n    ├── TASKS.md                     ← Phase 5: Ordered build checklist from the brief\n    ├── DESIGN_REVIEW.md             ← Phase 7: Prioritized critique against the brief\n    └── screenshots\u002F                 ← Phase 7: Visual evidence from the running app\n        ├── review-[page]-desktop-1280.png\n        ├── review-[page]-tablet-768.png\n        ├── review-[page]-mobile-375.png\n        ├── review-[page]-dark-mode-*.png\n        └── review-[component]-[state].png\n```\n\nThe `screenshots\u002F` subfolder is created during the design review phase. All visual evidence of the review (responsive breakpoints, interactive states, dark mode) is saved here with descriptive filenames so findings in `DESIGN_REVIEW.md` are traceable.\n\n## If the Designer Returns Mid-Flow\n\nCheck the `.design\u002F` folder for existing feature subfolders. If files from earlier phases exist (DESIGN_BRIEF.md, INFORMATION_ARCHITECTURE.md, TASKS.md) inside a feature folder, read them to understand where the designer left off. Ask which feature to resume if multiple folders exist. Resume from the next incomplete phase.\n",{"name":5,"description":7},"main","d8518247cb8ab8b2dac57a6be33543ffd23b97c5","design-ux\u002Fjulianoczkowski\u002Fdesign-flow",0,"https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry","https:\u002F\u002Fgithub.com\u002Fmattonweb","2026-05-29 08:42:23",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add mattonweb\u002Fai-assistant-foundry --skill design-flow",{"tool":67,"command":68},"bunx","bunx skills add mattonweb\u002Fai-assistant-foundry --skill design-flow",{"tool":70,"command":71},"pnpm","pnpm dlx skills add mattonweb\u002Fai-assistant-foundry --skill design-flow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fdesign-ux\u002Fjulianoczkowski\u002Fdesign-flow\u002FSKILL.md",true,[],[76,108,121,141,162,187],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":88,"publishedAt":49},"01M6P02DENRHN6KVGYC55FKASJ","writing-clearly-and-concisely","Use when writing prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Applies Strunk's timeless rules for clearer, stronger, more professional writing.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fsoftaworks\u002Fwriting-clearly-and-concisely\u002FSKILL.md",[82,85],{"categoryNo":83,"categoryName":84,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":86,"categoryName":87,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[89,90,91,92,93,94,95,96,97,98,99,32,100,101,102,103,104,105,106,107],"writing clearly and concisely","writing","concisely","text","for","more","timeless","error","professional","prose","reports","read","Rules","commit messages","messages","error messages","ui","documentation","commit",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":49},"01M6P0286HZ8RWMFCCPC8HF7SC","crafting-effective-readmes","Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fsoftaworks\u002Fcrafting-effective-readmes\u002FSKILL.md",[],[115,116,90,117,118,32,39,119,120],"crafting effective readmes","README","templates","type","guidance","files",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":130,"publishedAt":49},"01M6P025A41BBTPWVTZ3GFQVG6","wiki-architect","You are a documentation architect that produces structured wiki catalogues and onboarding guides from codebases.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fsickn33\u002Fwiki-architect\u002FSKILL.md",[127],{"categoryNo":128,"categoryName":129,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000038","人力资源",[131,132,133,134,135,136,137,138,139,140,106],"wiki","architect","wiki architect","unknown","you","documentation architect","guides","structured","community","onboarding",{"skillNo":142,"name":143,"nameZh":6,"description":144,"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":49},"01M6P01NSKPXP77NWB4K0PXRK5","readme","You are an expert technical writer creating comprehensive project documentation. Your goal is to write a README.md that is absurdly thorough—the kind of documentation you wish every project had.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fsickn33\u002Freadme\u002FSKILL.md",[],[116,148,149,150,135,151,152,39,153,154,54,155,156,157,158,159,106,160,161],"project documentation","tree","kind","expert","github","wish","writer","goal","write","technical writer","technical","https","write a readme","safe",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":49},"01M6P01GP0NEN8KT3A3SA6ZFVE","ubiquitous-language","Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions \"domain model\" or \"DDD\".","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fmattpocock\u002Fubiquitous-language\u002FSKILL.md",[],[169,170,32,171,172,173,174,175,176,177,40,178,179,180,181,182,183,184,185,186],"ubiquitous language","language","extract","user","glossary","model","terms","ddd","create","true","canonical","style","define","harden","domain model","domain","terminology","conversation",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":195,"publishedAt":49},"01M6P01BJBP9XP4TDRT7QD1ZVA","technical-writing-style","Enforce clear, direct writing in software development documents including OKRs, PRDs, tech specs, architecture decision records (ADRs), git commit messages, PR descriptions, READMEs, changelogs, runbooks, incident postmortems, API docs, and onboarding guides. Trigger whenever a user asks to write, edit, revise, or review any of these document types. Also trigger when the user says writing \"sounds like AI\", \"feels robotic\", \"needs polish\", or asks to \"make it sound more natural\" in the context of technical or professional prose. Do not trigger for fiction, poetry, creative writing, academic papers, or legal documents unless the user explicitly asks for a more natural tone.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fmattnebr\u002Ftechnical-writing-style\u002FSKILL.md",[193,194],{"categoryNo":83,"categoryName":84,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":86,"categoryName":87,"taxonomyType":26,"taxonomyTypeDesc":27},[196,197,180,158,90,198,97,199,200,201,202,203,204,205,206,103,207,208,107,48],"writing style","technical writing style","technical writing","papers","types","runbooks","software development","incident","Poetry","decision","api","documents","architecture"]