[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P68EFFVR0H5MXYF06X5A13":3,"skill-same:01M6P68EFFVR0H5MXYF06X5A13":97},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":76,"commitSha":77,"skillDirectory":78,"forksCount":79,"repositoryHtmlUrl":80,"repositoryHomepageUrl":6,"ownerHtmlUrl":81,"ownerBlogUrl":82,"ownerDescription":6,"updatedAt":83,"install":84,"resources":96},"01M6P68EFFVR0H5MXYF06X5A13","repo-status",null,"Produces a comprehensive `.status.md` status document combining filesystem exploration, semantic clusters, file importance ranking, and health assessment — a single artifact any agent or human can use as the starting point for a project. Use when: 'give me a complete repo overview', 'understand this codebase', 'create a system map', 'build a mental model', 'prepare a handoff document'.","DojoGenesis\u002Fgateway","DojoGenesis","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F273886418?v=4","01M6P54RXMD3TZ2082Z3Z4JMQP","Cruz Morales (TresPies)","01M6P54S269YR0ZZZ96WGQM439",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fsystem-health\u002Fskills\u002Frepo-status\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"status","repo status","repo","map","handoff","path","health assessment","sonnet","STRING","ranking","project","human","create","artifact","me","exploration","assessment","model","repository","generate","2026-11-10 10:12:30",false,"---\nname: repo-status\nmodel: sonnet\ndescription: \"Produces a comprehensive `.status.md` status document combining filesystem exploration, semantic clusters, file importance ranking, and health assessment — a single artifact any agent or human can use as the starting point for a project. Use when: 'give me a complete repo overview', 'understand this codebase', 'create a system map', 'build a mental model', 'prepare a handoff document'.\"\ncategory: system-health\ntriggers:\n  - \"give me a complete repo overview\"\n  - \"understand this codebase\"\n  - \"create a system map\"\n  - \"build a mental model\"\n  - \"prepare a handoff document\"\ntier: 1\nagents:\n  - \"primary\"\ntool_dependencies:\n  - \"file_system\"\n\ninputs:\n  - name: repo_path\n    type: string\n    description: Path to the repository to generate a status document for\n    required: true\noutputs:\n  - name: status_document\n    type: ref\n    format: cas-ref\n    description: Comprehensive .status.md combining filesystem exploration, semantic clusters, file importance ranking, and health assessment\n---\n\n# Repo Status Skill\n\n**Version:** 1.0\n**Created:** 2026-02-08\n**Author:** Cruz + Manus (Cowork)\n**Origin:** Codified from a live repo-context-sync + strategic-scout + status-writing session on Dojo Genesis.\n**Lineage:** status-writing + file-management + health-audit, distilled into a single repeatable workflow.\n\n---\n\n## I. The Philosophy: See the Whole Before Touching a Part\n\nMost codebases are explored piecemeal — someone reads a file, then another, then another, building a fragmentary picture that drifts as the project evolves. This skill takes the opposite approach: **see the whole system first, as a living organism**, then record what you see in a structured artifact that any future agent or human can use as a starting point.\n\nThe output is a `.status.md` file — a comprehensive, versioned snapshot that bridges three perspectives:\n\n- **Status Writer**: Emoji-driven health indicators, workstream tracking, blockers, next steps. The \"heartbeat\" view.\n- **File Management**: Annotated directory tree with per-folder status. The \"anatomy\" view.\n- **Health Supervisor**: Critical\u002Fsecurity\u002Fsustainability assessment. The \"checkup\" view.\n\nA single document. One place to look. Updated over time like a living record.\n\n---\n\n## II. When to Use This Skill\n\n- **Onboarding to a new project:** Before writing a single line, run this skill to build your mental model.\n- **Periodic health check:** Monthly or per-release, re-run to track drift and detect decay.\n- **Before a major refactor:** Understand what exists before deciding what to change.\n- **When handing off context:** Give another agent or team member a single file that tells them everything.\n- **When a project feels \"big\" or \"messy\":** Structure reduces anxiety. This skill imposes structure on chaos.\n\n---\n\n## III. The Workflow\n\nThis is a 5-phase process. Each phase builds on the previous one.\n\n### Phase 1: Grounding (Read Before You Judge)\n\n**Objective:** Understand what the project *is* before evaluating how well it works.\n\n1. **List the root directory.** Get the top-level shape.\n2. **Read core documents.** In priority order:\n   - `README.md` (what it is, how to run it)\n   - `STATUS.md` or equivalent (where it is right now)\n   - `CHANGELOG.md` or release notes (where it's been)\n   - `package.json`, `go.mod`, `Cargo.toml`, `pyproject.toml` (tech stack, deps)\n   - `ARCHITECTURE.md`, `PHILOSOPHY.md` if they exist (intent, design)\n3. **Identify the tech stack.** Language(s), framework(s), database(s), infra.\n4. **Note the project's self-stated purpose.** This becomes Section 1 of the output.\n\n*Time budget: ~10% of total effort. Resist the urge to explore deeply here.*\n\n### Phase 2: Deep Inventory (Parallel Exploration)\n\n**Objective:** Build a complete picture of everything in the repository.\n\nLaunch parallel exploration across the major layers. For most projects, these are:\n\n| Layer | What to Inventory |\n|-------|-------------------|\n| **Frontend** | Components, routes, state management, styling, tests, LOC estimates |\n| **Backend** | Packages, handlers, services, models, LOC estimates |\n| **Data** | Migrations, schemas, seed data, vector stores |\n| **Knowledge** | Docs, skills, prompts, thinking artifacts, compressions |\n| **Infra** | CI\u002FCD, Docker, scripts, deployment configs |\n| **Tests** | Unit, integration, e2e, coverage estimates |\n\nFor each layer, collect:\n- File count\n- Approximate LOC (use `wc -l` or `cloc` if available)\n- Package\u002Fmodule count\n- Status (active, legacy, deprecated, empty)\n\n*Time budget: ~30% of total effort. Parallelize aggressively.*\n\n### Phase 3: Semantic Clustering\n\n**Objective:** Group everything by *what the system does*, not where files happen to live.\n\nThis is the distinctive step. Instead of just listing directories, map every feature to an **action verb** — a cluster that describes a behavioral capability of the system.\n\nRead `references\u002Fsemantic-clusters.md` for the full cluster framework and examples.\n\n**The process:**\n\n1. Review the inventory from Phase 2.\n2. For each significant component, ask: \"What verb describes what this does?\"\n3. Assign it to a cluster. Create new clusters if needed.\n4. For each cluster, build a component table: `Component | Location | Status | LOC`\n5. Write a health assessment per cluster.\n6. Identify cross-cluster components (things that serve multiple verbs).\n7. Identify orphans (components that don't fit any cluster) — these may signal architectural confusion.\n\n*Time budget: ~25% of total effort. This is where the insight lives.*\n\n### Phase 4: Write the .status.md\n\n**Objective:** Assemble everything into a single, structured document.\n\nRead `references\u002Fstatus-template.md` for the complete output template.\n\nThe document has 10 sections:\n\n1. **Vision & Purpose** — One sentence + core principles (from Phase 1)\n2. **Current State** — Emoji table of major areas (from Phase 2)\n3. **Directory Structure** — Annotated tree with per-folder status (from Phase 2)\n4. **Semantic Clusters** — One subsection per verb, with component tables (from Phase 3)\n5. **File Importance Ranking** — 4 tiers (Critical, Important, Supporting, Knowledge)\n6. **Health Assessment** — Critical issues, security, sustainability (health-audit framework)\n7. **Active Workstreams** — What's being worked on right now\n8. **Blockers & Dependencies** — What's preventing progress\n9. **Next Steps** — Immediate actionable items\n10. **Aggregate Statistics** — Summary numbers table\n\nSave to `.status.md` at the project root (dot-prefixed to stay out of the way but discoverable).\n\n*Time budget: ~25% of total effort.*\n\n### Phase 5: Verification\n\n**Objective:** Catch errors, fill gaps, and harden the document.\n\n1. **Cross-check statistics programmatically.** Run `find` and `wc -l` to verify LOC claims. Check file counts against actual filesystem.\n2. **Identify unmapped components.** Walk the component directories and confirm every significant directory appears in at least one semantic cluster.\n3. **Validate status emojis.** Ensure every area marked \"complete\" actually has evidence of completeness.\n4. **Apply corrections.** Update the `.status.md` with any discrepancies found.\n5. **Note confidence level.** If you couldn't verify something, say so.\n\n*Time budget: ~10% of total effort. This step prevents the document from being fiction.*\n\n---\n\n## IV. The Semantic Cluster Framework\n\nThe clusters are action verbs that describe what a system *does*. For the full reference with starter verbs and mapping guidance, read:\n\n```\nreferences\u002Fsemantic-clusters.md\n```\n\n**Starter set (adapt to your project):**\n\n| Verb | Meaning | Example Components |\n|------|---------|-------------------|\n| CONVERSE | Chat, messaging, streaming | Chat UI, SSE handlers, message models |\n| REASON | Thinking, planning, deciding | Agent, intent classifier, orchestration |\n| REMEMBER | Storage, recall, learning | Memory system, embeddings, seeds |\n| OBSERVE | Monitoring, tracing, metrics | Trace logger, event bus, cost tracker |\n| LEARN | Adaptation, feedback, calibration | Calibration engine, preference system |\n| ACT | Tool execution, side effects | Tool registry, tool implementations |\n| PROTECT | Auth, security, boundaries | Middleware, secure storage, auth context |\n| CONNECT | External integrations | Plugins, APIs, bots, webhooks |\n| PRESENT | UI, rendering, layout | Shell, sidebars, panels, components |\n| PERSIST | Database, migrations, storage | DB manager, migrations, schemas |\n| BUILD | CI\u002FCD, testing, deployment | Workflows, Docker, scripts, tests |\n| THINK | Meta-cognition, knowledge | Skills, prompts, documentation |\n| ORCHESTRATE | Multi-step coordination | DAG engine, task decomposition |\n\nNot every project will use all 13. Some projects may need verbs not on this list. The framework is a starting point, not a constraint.\n\n---\n\n## V. File Importance Ranking\n\nRank files into 4 tiers based on runtime criticality and development importance:\n\n| Tier | Criteria | Typical Count |\n|------|----------|---------------|\n| **Tier 1: Critical** | System won't function without these. Core agent, main state, primary API endpoint, database manager. | 10 files |\n| **Tier 2: Important** | Core features break without these. Supporting services, secondary state, routing. | 10 files |\n| **Tier 3: Supporting** | System degrades gracefully without these. Integrations, utilities, background tasks. | 20-30 files |\n| **Tier 4: Knowledge** | Essential for development, not runtime. Docs, specs, skills, prompts. | Variable |\n\nFor each file in Tiers 1-2, include `Rank | File | Why` — a one-line justification.\n\n---\n\n## VI. Health Assessment Framework\n\nBorrowed directly from the health-audit skill. For each category, use a table with `Area | Status | Notes`.\n\n| Category | What to Check |\n|----------|--------------|\n| **Critical Issues** | Can it build? Critical dependency vulnerabilities? Main branch broken? |\n| **Security** | Secrets hardcoded? Auth implemented? RLS policies set? Encryption at rest? |\n| **Sustainability** | Test coverage adequate? CI\u002FCD automated? Technical debt managed? Docs current? Manual processes documented? |\n\nBe honest. Use emoji status indicators: ✅ good, ⚠️ concern, ❌ blocked.\n\n---\n\n## VII. Best Practices\n\n- **Dot-prefix the output file.** `.status.md` stays discoverable but doesn't clutter the root alongside README and STATUS.\n- **Separate from STATUS.md.** The lightweight `STATUS.md` (per status-writing skill) is the human-facing dashboard. `.status.md` is the comprehensive agent-facing audit. They complement each other.\n- **Update incrementally.** After the first generation, subsequent runs should diff against the existing `.status.md` and update rather than regenerate from scratch.\n- **Statistics drift is normal.** LOC counts change every commit. The goal is \"accurate enough to be useful\" — within 10% is fine.\n- **Semantic clusters are the crown jewel.** The directory tree tells you *where* things are. The clusters tell you *what* things do. Prioritize cluster quality over tree completeness.\n- **Parallelize Phase 2.** The deep inventory is the slowest phase. Use subagents or parallel exploration to cut time.\n- **Verification is not optional.** A beautiful document full of wrong numbers is worse than no document. Always verify.\n\n---\n\n## VIII. Quality Checklist\n\nBefore delivering the `.status.md`, confirm:\n\n- [ ] Vision statement is present and accurate\n- [ ] Every major directory appears in the annotated tree\n- [ ] Every significant component maps to at least one semantic cluster\n- [ ] No orphan directories (unmapped components) remain unexplained\n- [ ] File importance ranking has at least 10 Tier 1-2 files\n- [ ] Health assessment covers critical, security, and sustainability\n- [ ] Aggregate statistics are programmatically verified (within 10%)\n- [ ] Active workstreams reflect actual current work\n- [ ] Next steps are concrete and actionable\n- [ ] The document reads coherently from top to bottom\n\n## Output\n- `.status.md` saved at the project root (dot-prefixed, stays discoverable without cluttering the root alongside README).\n- Ten sections: Vision and Purpose, Current State (emoji table), Directory Structure (annotated tree), Semantic Clusters (per-verb component tables), File Importance Ranking (4 tiers), Health Assessment, Active Workstreams, Blockers and Dependencies, Next Steps, Aggregate Statistics.\n\n## Examples\n**Scenario 1:** \"Give me a complete overview of the Gateway repo before the sprint\" → `.status.md` generated with all 10 sections. Semantic clusters reveal REASON and ORCHESTRATE are the most complex clusters. Health assessment surfaces a missing CI\u002FCD config as a sustainability concern.\n**Scenario 2:** \"Prepare a handoff doc for the HTMLCraft Studio\" → `.status.md` produced for a Wails v2 + Go project. 8-module architecture mapped into 5 clusters. Tier 1 files identified. Handed off to incoming agent who begins from the status doc rather than a 30-minute walkthrough.\n\n## Edge Cases\n- If the project has fewer than 50 files, skip semantic clusters (Section 4) and file importance ranking (Section 5) — they add little value at small scale.\n- On subsequent runs, diff against the existing `.status.md` and update incrementally rather than regenerating from scratch — especially critical for aggregate statistics that change with every commit.\n\n## Anti-Patterns\n- Conflating this skill with `health-audit` — repo-status produces status documents; health-audit produces engineering commissions. The outputs are complementary but distinct.\n- Verifying statistics by estimation rather than running `find` and `wc -l` — a beautiful document full of wrong numbers is worse than no document.\n","# Repo Status Skill\n\n**Version:** 1.0\n**Created:** 2026-02-08\n**Author:** Cruz + Manus (Cowork)\n**Origin:** Codified from a live repo-context-sync + strategic-scout + status-writing session on Dojo Genesis.\n**Lineage:** status-writing + file-management + health-audit, distilled into a single repeatable workflow.\n\n---\n\n## I. The Philosophy: See the Whole Before Touching a Part\n\nMost codebases are explored piecemeal — someone reads a file, then another, then another, building a fragmentary picture that drifts as the project evolves. This skill takes the opposite approach: **see the whole system first, as a living organism**, then record what you see in a structured artifact that any future agent or human can use as a starting point.\n\nThe output is a `.status.md` file — a comprehensive, versioned snapshot that bridges three perspectives:\n\n- **Status Writer**: Emoji-driven health indicators, workstream tracking, blockers, next steps. The \"heartbeat\" view.\n- **File Management**: Annotated directory tree with per-folder status. The \"anatomy\" view.\n- **Health Supervisor**: Critical\u002Fsecurity\u002Fsustainability assessment. The \"checkup\" view.\n\nA single document. One place to look. Updated over time like a living record.\n\n---\n\n## II. When to Use This Skill\n\n- **Onboarding to a new project:** Before writing a single line, run this skill to build your mental model.\n- **Periodic health check:** Monthly or per-release, re-run to track drift and detect decay.\n- **Before a major refactor:** Understand what exists before deciding what to change.\n- **When handing off context:** Give another agent or team member a single file that tells them everything.\n- **When a project feels \"big\" or \"messy\":** Structure reduces anxiety. This skill imposes structure on chaos.\n\n---\n\n## III. The Workflow\n\nThis is a 5-phase process. Each phase builds on the previous one.\n\n### Phase 1: Grounding (Read Before You Judge)\n\n**Objective:** Understand what the project *is* before evaluating how well it works.\n\n1. **List the root directory.** Get the top-level shape.\n2. **Read core documents.** In priority order:\n   - `README.md` (what it is, how to run it)\n   - `STATUS.md` or equivalent (where it is right now)\n   - `CHANGELOG.md` or release notes (where it's been)\n   - `package.json`, `go.mod`, `Cargo.toml`, `pyproject.toml` (tech stack, deps)\n   - `ARCHITECTURE.md`, `PHILOSOPHY.md` if they exist (intent, design)\n3. **Identify the tech stack.** Language(s), framework(s), database(s), infra.\n4. **Note the project's self-stated purpose.** This becomes Section 1 of the output.\n\n*Time budget: ~10% of total effort. Resist the urge to explore deeply here.*\n\n### Phase 2: Deep Inventory (Parallel Exploration)\n\n**Objective:** Build a complete picture of everything in the repository.\n\nLaunch parallel exploration across the major layers. For most projects, these are:\n\n| Layer | What to Inventory |\n|-------|-------------------|\n| **Frontend** | Components, routes, state management, styling, tests, LOC estimates |\n| **Backend** | Packages, handlers, services, models, LOC estimates |\n| **Data** | Migrations, schemas, seed data, vector stores |\n| **Knowledge** | Docs, skills, prompts, thinking artifacts, compressions |\n| **Infra** | CI\u002FCD, Docker, scripts, deployment configs |\n| **Tests** | Unit, integration, e2e, coverage estimates |\n\nFor each layer, collect:\n- File count\n- Approximate LOC (use `wc -l` or `cloc` if available)\n- Package\u002Fmodule count\n- Status (active, legacy, deprecated, empty)\n\n*Time budget: ~30% of total effort. Parallelize aggressively.*\n\n### Phase 3: Semantic Clustering\n\n**Objective:** Group everything by *what the system does*, not where files happen to live.\n\nThis is the distinctive step. Instead of just listing directories, map every feature to an **action verb** — a cluster that describes a behavioral capability of the system.\n\nRead `references\u002Fsemantic-clusters.md` for the full cluster framework and examples.\n\n**The process:**\n\n1. Review the inventory from Phase 2.\n2. For each significant component, ask: \"What verb describes what this does?\"\n3. Assign it to a cluster. Create new clusters if needed.\n4. For each cluster, build a component table: `Component | Location | Status | LOC`\n5. Write a health assessment per cluster.\n6. Identify cross-cluster components (things that serve multiple verbs).\n7. Identify orphans (components that don't fit any cluster) — these may signal architectural confusion.\n\n*Time budget: ~25% of total effort. This is where the insight lives.*\n\n### Phase 4: Write the .status.md\n\n**Objective:** Assemble everything into a single, structured document.\n\nRead `references\u002Fstatus-template.md` for the complete output template.\n\nThe document has 10 sections:\n\n1. **Vision & Purpose** — One sentence + core principles (from Phase 1)\n2. **Current State** — Emoji table of major areas (from Phase 2)\n3. **Directory Structure** — Annotated tree with per-folder status (from Phase 2)\n4. **Semantic Clusters** — One subsection per verb, with component tables (from Phase 3)\n5. **File Importance Ranking** — 4 tiers (Critical, Important, Supporting, Knowledge)\n6. **Health Assessment** — Critical issues, security, sustainability (health-audit framework)\n7. **Active Workstreams** — What's being worked on right now\n8. **Blockers & Dependencies** — What's preventing progress\n9. **Next Steps** — Immediate actionable items\n10. **Aggregate Statistics** — Summary numbers table\n\nSave to `.status.md` at the project root (dot-prefixed to stay out of the way but discoverable).\n\n*Time budget: ~25% of total effort.*\n\n### Phase 5: Verification\n\n**Objective:** Catch errors, fill gaps, and harden the document.\n\n1. **Cross-check statistics programmatically.** Run `find` and `wc -l` to verify LOC claims. Check file counts against actual filesystem.\n2. **Identify unmapped components.** Walk the component directories and confirm every significant directory appears in at least one semantic cluster.\n3. **Validate status emojis.** Ensure every area marked \"complete\" actually has evidence of completeness.\n4. **Apply corrections.** Update the `.status.md` with any discrepancies found.\n5. **Note confidence level.** If you couldn't verify something, say so.\n\n*Time budget: ~10% of total effort. This step prevents the document from being fiction.*\n\n---\n\n## IV. The Semantic Cluster Framework\n\nThe clusters are action verbs that describe what a system *does*. For the full reference with starter verbs and mapping guidance, read:\n\n```\nreferences\u002Fsemantic-clusters.md\n```\n\n**Starter set (adapt to your project):**\n\n| Verb | Meaning | Example Components |\n|------|---------|-------------------|\n| CONVERSE | Chat, messaging, streaming | Chat UI, SSE handlers, message models |\n| REASON | Thinking, planning, deciding | Agent, intent classifier, orchestration |\n| REMEMBER | Storage, recall, learning | Memory system, embeddings, seeds |\n| OBSERVE | Monitoring, tracing, metrics | Trace logger, event bus, cost tracker |\n| LEARN | Adaptation, feedback, calibration | Calibration engine, preference system |\n| ACT | Tool execution, side effects | Tool registry, tool implementations |\n| PROTECT | Auth, security, boundaries | Middleware, secure storage, auth context |\n| CONNECT | External integrations | Plugins, APIs, bots, webhooks |\n| PRESENT | UI, rendering, layout | Shell, sidebars, panels, components |\n| PERSIST | Database, migrations, storage | DB manager, migrations, schemas |\n| BUILD | CI\u002FCD, testing, deployment | Workflows, Docker, scripts, tests |\n| THINK | Meta-cognition, knowledge | Skills, prompts, documentation |\n| ORCHESTRATE | Multi-step coordination | DAG engine, task decomposition |\n\nNot every project will use all 13. Some projects may need verbs not on this list. The framework is a starting point, not a constraint.\n\n---\n\n## V. File Importance Ranking\n\nRank files into 4 tiers based on runtime criticality and development importance:\n\n| Tier | Criteria | Typical Count |\n|------|----------|---------------|\n| **Tier 1: Critical** | System won't function without these. Core agent, main state, primary API endpoint, database manager. | 10 files |\n| **Tier 2: Important** | Core features break without these. Supporting services, secondary state, routing. | 10 files |\n| **Tier 3: Supporting** | System degrades gracefully without these. Integrations, utilities, background tasks. | 20-30 files |\n| **Tier 4: Knowledge** | Essential for development, not runtime. Docs, specs, skills, prompts. | Variable |\n\nFor each file in Tiers 1-2, include `Rank | File | Why` — a one-line justification.\n\n---\n\n## VI. Health Assessment Framework\n\nBorrowed directly from the health-audit skill. For each category, use a table with `Area | Status | Notes`.\n\n| Category | What to Check |\n|----------|--------------|\n| **Critical Issues** | Can it build? Critical dependency vulnerabilities? Main branch broken? |\n| **Security** | Secrets hardcoded? Auth implemented? RLS policies set? Encryption at rest? |\n| **Sustainability** | Test coverage adequate? CI\u002FCD automated? Technical debt managed? Docs current? Manual processes documented? |\n\nBe honest. Use emoji status indicators: ✅ good, ⚠️ concern, ❌ blocked.\n\n---\n\n## VII. Best Practices\n\n- **Dot-prefix the output file.** `.status.md` stays discoverable but doesn't clutter the root alongside README and STATUS.\n- **Separate from STATUS.md.** The lightweight `STATUS.md` (per status-writing skill) is the human-facing dashboard. `.status.md` is the comprehensive agent-facing audit. They complement each other.\n- **Update incrementally.** After the first generation, subsequent runs should diff against the existing `.status.md` and update rather than regenerate from scratch.\n- **Statistics drift is normal.** LOC counts change every commit. The goal is \"accurate enough to be useful\" — within 10% is fine.\n- **Semantic clusters are the crown jewel.** The directory tree tells you *where* things are. The clusters tell you *what* things do. Prioritize cluster quality over tree completeness.\n- **Parallelize Phase 2.** The deep inventory is the slowest phase. Use subagents or parallel exploration to cut time.\n- **Verification is not optional.** A beautiful document full of wrong numbers is worse than no document. Always verify.\n\n---\n\n## VIII. Quality Checklist\n\nBefore delivering the `.status.md`, confirm:\n\n- [ ] Vision statement is present and accurate\n- [ ] Every major directory appears in the annotated tree\n- [ ] Every significant component maps to at least one semantic cluster\n- [ ] No orphan directories (unmapped components) remain unexplained\n- [ ] File importance ranking has at least 10 Tier 1-2 files\n- [ ] Health assessment covers critical, security, and sustainability\n- [ ] Aggregate statistics are programmatically verified (within 10%)\n- [ ] Active workstreams reflect actual current work\n- [ ] Next steps are concrete and actionable\n- [ ] The document reads coherently from top to bottom\n\n## Output\n- `.status.md` saved at the project root (dot-prefixed, stays discoverable without cluttering the root alongside README).\n- Ten sections: Vision and Purpose, Current State (emoji table), Directory Structure (annotated tree), Semantic Clusters (per-verb component tables), File Importance Ranking (4 tiers), Health Assessment, Active Workstreams, Blockers and Dependencies, Next Steps, Aggregate Statistics.\n\n## Examples\n**Scenario 1:** \"Give me a complete overview of the Gateway repo before the sprint\" → `.status.md` generated with all 10 sections. Semantic clusters reveal REASON and ORCHESTRATE are the most complex clusters. Health assessment surfaces a missing CI\u002FCD config as a sustainability concern.\n**Scenario 2:** \"Prepare a handoff doc for the HTMLCraft Studio\" → `.status.md` produced for a Wails v2 + Go project. 8-module architecture mapped into 5 clusters. Tier 1 files identified. Handed off to incoming agent who begins from the status doc rather than a 30-minute walkthrough.\n\n## Edge Cases\n- If the project has fewer than 50 files, skip semantic clusters (Section 4) and file importance ranking (Section 5) — they add little value at small scale.\n- On subsequent runs, diff against the existing `.status.md` and update incrementally rather than regenerating from scratch — especially critical for aggregate statistics that change with every commit.\n\n## Anti-Patterns\n- Conflating this skill with `health-audit` — repo-status produces status documents; health-audit produces engineering commissions. The outputs are complementary but distinct.\n- Verifying statistics by estimation rather than running `find` and `wc -l` — a beautiful document full of wrong numbers is worse than no document.\n",{"name":5,"tier":52,"model":34,"agents":53,"inputs":55,"outputs":61,"category":67,"triggers":68,"description":7,"tool_dependencies":74},1,[54],"primary",[56],{"name":57,"type":58,"required":59,"description":60},"repo_path","string",true,"Path to the repository to generate a status document for",[62],{"name":63,"type":64,"format":65,"description":66},"status_document","ref","cas-ref","Comprehensive .status.md combining filesystem exploration, semantic clusters, file importance ranking, and health assessment","system-health",[69,70,71,72,73],"give me a complete repo overview","understand this codebase","create a system map","build a mental model","prepare a handoff document",[75],"file_system","main","ff07df5fd8f75762c2a131e6e26d297e8ae403ee","plugins\u002Fsystem-health\u002Fskills\u002Frepo-status",0,"https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway","https:\u002F\u002Fgithub.com\u002FDojoGenesis","dojogenesis.com","2026-10-25 22:59:58",{"source":8,"skillName":5,"commands":85,"prompt":95,"zipAvailable":59},[86,89,92],{"tool":87,"command":88},"npx","npx skills add DojoGenesis\u002Fgateway --skill repo-status",{"tool":90,"command":91},"bunx","bunx skills add DojoGenesis\u002Fgateway --skill repo-status",{"tool":93,"command":94},"pnpm","pnpm dlx skills add DojoGenesis\u002Fgateway --skill repo-status","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fsystem-health\u002Fskills\u002Frepo-status\u002FSKILL.md",[],[98,117,128,136,174,199],{"skillNo":99,"name":100,"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":101,"categories":102,"keywords":106,"publishedAt":47},"01M6P6J0WYSD1MTGA3ZX6MGGZ5","kata-test-echo","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-test-echo\u002FSKILL.md",[103],{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[107,108,109,110,111,112,113,114,115,116],"kata test echo","Echo","test","json","v1","output","input","structured","contracts","schema",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":124,"publishedAt":47},"01M6P6HQJNGG4WPZW0DEWMAY2N","kata-plain","An ordinary prose skill; not dispatchable.","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-plain\u002FSKILL.md",[123],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[125,126,127],"kata plain","prose skill","prose",{"skillNo":129,"name":130,"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":131,"categories":132,"keywords":133,"publishedAt":47},"01M6P6HH6Y7K8K6606MF7VZ1HB","kata-broken","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fserver\u002Ftestdata\u002Fkata\u002Fskills\u002Fkata-broken\u002FSKILL.md",[],[134,135,114,115,108,116,110,109,113,111,112],"kata broken","broken",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":156,"publishedAt":47},"01M6P6GW520QJ03A6K7Y5PWJ52","voice-before-structure","Read the project's design language and philosophy before writing structural artifacts. Ground manifests, READMEs, and descriptions in the project's voice, not boilerplate. Use when creating manifests or READMEs for established projects, writing ecosystem-level documentation, building plugin descriptions or marketplace metadata, or authoring metadata that carries a project's identity. Trigger phrases: 'write the manifest', 'create a README', 'describe this plugin', 'ground yourself in the philosophy', 'ecosystem-level work'.","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fvoice-before-structure\u002FSKILL.md",[142,145,148,153],{"categoryNo":143,"categoryName":144,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":146,"categoryName":147,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":149,"categoryName":150,"taxonomyType":151,"taxonomyTypeDesc":152},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":154,"categoryName":155,"taxonomyType":151,"taxonomyTypeDesc":152},"01JBSEEDCAT000000000000036","内容创作者",[157,158,159,160,161,162,163,164,37,40,165,166,167,168,169,39,170,171,172,173],"voice before structure","structure","voice","manifests","ecosystem","false","authoring","structural","philosophy","design","writing","identity","documentation","projects","work","read","write",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":181,"publishedAt":47},"01M6P6GMNA4HJ4D5RRM3BQZ73M","system-prompt-archaeology","Produces a named ADA disposition preset (YAML) and a layered behavioral analysis (structural decomposition + evidence-cited classifications) from a system prompt. Use when: \"analyze this system prompt\", \"extract disposition from prompt\", \"reverse-engineer agent behavior\", \"what patterns does this prompt use\", \"build a preset from this prompt\".","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fsystem-prompt-archaeology\u002FSKILL.md",[180],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[182,183,184,185,186,187,164,188,189,190,191,192,193,194,195,196,35,34,197,198],"system prompt archaeology","system prompt","prompt","system","behavioral","classify","decomposition","wisdom","patterns","engineer","decompose","evidence","ada","analyze","analysis","true","reverse",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":206,"publishedAt":47},"01M6P6G2D70T9R00HX6K154X5Y","session-lifecycle-automation","Designs and configures all three loops of solo-operator session automation — session bookends, background maintenance agents, and a delegation flywheel. Use when setting up a new workspace, recovering from the 44% zero-artifact session leak, or preparing to scale delegation across multiple concurrent agents.","https:\u002F\u002Fgithub.com\u002FDojoGenesis\u002Fgateway\u002Fblob\u002Fmain\u002Fplugins\u002Fwisdom-garden\u002Fskills\u002Fsession-lifecycle-automation\u002FSKILL.md",[205],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[207,208,209,210,211,212,213,214,215,216,217,218,219,40,220,221,222,223,224,225],"automation","session lifecycle automation","session lifecycle","lifecycle","session","markdown","configure","directory","config","delegation","audit","SET","files","solo","across","scheduled","loops","up","template"]