grace-ask
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.
git clone --depth 1 https://github.com/osovv/grace-marketplace /tmp/grace-ask && cp -r /tmp/grace-ask/skills/grace/grace-ask ~/.claude/skills/grace-askSKILL.md
Answer a question about the current GRACE project. ## Process ### Step 1: Load Project Context Read the following files (skip any that don't exist): 1. `AGENTS.md` — project principles and conventions 2. `docs/knowledge-graph.xml` — module map, dependencies, exports 3. `docs/requirements.xml` — use cases and requirements 4. `docs/technology.xml` — stack, runtime, libraries 5. `docs/development-plan.xml` — phases, modules, contracts 6. `docs/verification-plan.xml` — tests, traces, log markers, and execution gates 7. `docs/operational-packets.xml` — canonical packet, delta, and failure handoff shapes ### Step 2: Identify Relevant Modules Based on the question, find the most relevant modules: 1. Use the knowledge graph to locate modules related to the question 2. Follow CrossLinks to find connected modules 3. Read MODULE_CONTRACTs of relevant modules for detailed context 4. Read matching verification entries when the question is about behavior, failure modes, or testing If the optional `grace` CLI is available, you may use: - `grace module find <query> --path <project-root>` to resolve module IDs from names, paths, dependencies, or verification refs - `grace module show M-XXX --path <project-root> --with verification` to pull the shared/public module snapshot - `grace file show <path> --path <project-root> --contracts --blocks` to pull file-local/private context for the implementation details ### Step 3: Dive Into Code If Needed If the question is about specific behavior or implementation: 1. Use MODULE_MAP to locate relevant functions/blocks 2. Read the specific START_BLOCK/END_BLOCK sections 3. Read function CONTRACTs for intent vs implementation details 4. Read nearby tests or log-marker assertions when they are the strongest evidence for expected behavior ### Step 4: Answer Provide a clear, concise answer grounded in the actual project artifacts. Always cite which files/modules/blocks your answer is based on. ### Important - Never guess — if the information isn't in the project artifacts, say so - If the question reveals a gap in documentation or contracts, mention it - If the question reveals a gap in tests, traces, or verification docs, mention it - If the answer requires changes to the project, suggest the appropriate `$grace-*` skill
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.
Refactor GRACE-governed code safely: rename, move, split, merge, or extract modules while keeping contracts, graph, verification, and semantic markup synchronized.