grace-status
Show the current health status of a GRACE project. Use to get an overview of project artifacts, codebase metrics, knowledge graph health, verification coverage, and suggested next actions.
git clone --depth 1 https://github.com/osovv/grace-marketplace /tmp/grace-status && cp -r /tmp/grace-status/skills/grace/grace-status ~/.claude/skills/grace-statusSKILL.md
Show the current state of the GRACE project, including whether it is safe to hand to a longer autonomous run. When the optional CLI is available, prefer `grace status --path <project-root>` for the initial report. Use `grace status --with modules --path <project-root>` when project-level health is not enough and you need module summaries before deeper investigation. ## Report Contents ### 1. Artifacts Status Check existence and version of: - [ ] `AGENTS.md` — GRACE principles - [ ] `docs/knowledge-graph.xml` — version and module count - [ ] `docs/requirements.xml` — version and UseCase count - [ ] `docs/technology.xml` — version and stack summary - [ ] `docs/development-plan.xml` — version and module count - [ ] `docs/verification-plan.xml` — version and verification entry count - [ ] `docs/operational-packets.xml` — optional packet template version ### 2. Codebase Metrics Scan source files and report: - Total source files - Files WITH MODULE_CONTRACT - Files WITHOUT MODULE_CONTRACT (warning) - Total test files - Test files WITH MODULE_CONTRACT - Total semantic blocks (START_BLOCK / END_BLOCK pairs) - Unpaired blocks (integrity violation) - Files with stable log markers - Test files that assert log markers or traces when relevant ### 3. Knowledge Graph and Verification Health Quick check: - Modules in graph vs modules in codebase - Any orphaned or missing entries - Modules in verification plan vs modules in development plan - Missing or stale verification refs - Pending phases and steps that still need execution - Autonomy blockers from `grace lint --profile autonomous` If the optional `grace` CLI is available, you may also run `grace lint --path <project-root>` as a fast integrity snapshot and include any relevant findings in the report. If the report is specifically about autonomous execution readiness, also run `grace lint --profile autonomous --path <project-root>` and summarize blockers versus warnings. When the report needs focused navigation instead of raw artifact dumps, you may also use: - `grace module find <query> --path <project-root>` to resolve the relevant module from names, IDs, dependencies, or changed paths - `grace module show M-XXX --path <project-root> --with verification,health` for the shared/public module snapshot - `grace module health M-XXX --path <project-root>` for the module-scoped blockers, warnings, and next action - `grace verification show V-M-XXX --path <project-root>` for the linked verification entry itself - `grace file show <path> --path <project-root> --contracts --blocks` for the file-local/private markup snapshot ### 4. Recent Changes List the 5 most recent CHANGE_SUMMARY entries across source and substantive test files. ### 5. Suggested Next Action Based on the status, suggest what to do next: - If no requirements — "Define requirements in docs/requirements.xml" - If requirements but no plan — "Run `$grace-plan`" - If plan exists but verification is still thin — "Run `$grace-verification`" - If plan and verification are ready but modules are missing — "Run `$grace-execute` or `$grace-multiagent-execute`" - If drift detected — "Run `$grace-refresh`" - If fast integrity signals are needed before deeper review — "Run `grace lint --path <project-root>`" - If one lint code needs direct remediation guidance — "Run `grace lint --explain <code>`" - If the next step is targeted investigation of one module or file — "Run `grace module show M-XXX --path <project-root> --with verification` or `grace file show <path> --path <project-root> --contracts --blocks`" - If tests or logs are too weak for autonomous work — "Run `$grace-verification`" - If autonomy blockers are present — "Run `grace lint --profile autonomous --path <project-root>` and strengthen verification or packet quality before execution" - If everything synced — "Project is healthy"
Answer a question about a GRACE project using full project context. Use when the user has a question about the codebase, architecture, modules, or implementation — loads all GRACE artifacts, navigates the knowledge graph, and provides a grounded answer with citations.
Operate the optional `grace` CLI against a GRACE project. Use when you want to lint GRACE artifacts, explain/remediate lint issues, check autonomy readiness, inspect project or module health, inspect verification entries, resolve modules from names or file paths, inspect shared/public module context, or inspect file-local/private markup through `grace lint`, `grace status`, `grace module`, `grace verification`, and `grace file show`.
Execute the full GRACE development plan step by step with controller-managed context packets, verification-plan excerpts, scoped reviews, level-based verification, and commits after validated sequential steps.
Complete GRACE methodology reference. Use when explaining GRACE to users, onboarding new projects, or when you need to understand the GRACE framework - its principles, semantic markup, knowledge graphs, contracts, testing, and unique tag conventions.
Debug an issue using GRACE semantic navigation. Use when encountering bugs, errors, or unexpected behavior - navigate through the graph, verification plan, and semantic blocks to analyze the mismatch and apply a targeted fix.
Bootstrap GRACE framework structure for a new project. Use when starting a new project with GRACE methodology - creates docs/ directory, AGENTS.md, and XML templates for requirements, technology, development plan, verification plan, knowledge graph, and operational packet contracts.
Execute a GRACE development plan in controller-managed parallel waves with selectable safety profiles, verification-plan excerpts, batched shared-artifact sync, and scoped reviews.
Run the GRACE architectural planning phase. Use when you have requirements and technology decisions defined and need to design the module architecture, create contracts, map data flows, and establish verification references. Produces development-plan.xml, verification-plan.xml, and knowledge-graph.xml.