agile-context-engineering 0.2.2 → 0.5.0

package/agile-context-engineering/templates/_command.md

@@ -1,54 +0,0 @@
----
-name: ace:COMMAND_NAME
-description: COMMAND_DESCRIPTION
-argument-hint: ""
-allowed-tools:
-  - Read
-  - Bash
-  - Glob
-  - Grep
-  - Write
-  - Task
----
-
-```xml
-<command>
-	
-	<execution-time>
-	</execution-time>
-	
-    <input>
-        <flags>
-		</flags>
-        
-        <parameters>
-            <required>
-			</required>
-			
-            <optional>
-			</optional>
-        </parameters>
-    </input>
-
-    <execution-context>
-    </execution-context>
-
-    <output>
-        <objective>
-        </objective>
-        
-        <artifacts>
-        </artifacts>
-    </output>
-    
-    <process>
-    </process>
-
-    <success_criteria>
-    </success_criteria>
-    
-    <next-steps>
-    </next-steps>
-
-</command>
-```

package/agile-context-engineering/templates/_workflow.xml

@@ -1,17 +0,0 @@
-<workflow>
-
-    <purpose>
-    </purpose>
-
-    <mandatory-context>
-        [TODO] Read all files referenced by the invoking prompt's execution-context before starting. Also Read any document or text passed as parameter in the invoking command that called this template.
-    </mandatory-context>
-
-    <process>
-        <step name="1">
-        </step>
-
-        <step name="2">
-        </step>
-    </process>
-</workflow>

package/agile-context-engineering/templates/wiki/wiki-readme.xml

@@ -1,276 +0,0 @@
-<wiki-readme>
-    <purpose>
-        Template for `.docs/wiki/wiki-readme.md` — the entry point and usage guide for the
-        engineering wiki. Generated once when the `.docs/wiki/` directory is first created
-        (typically by `/ace:map-system`).
-
-        Serves two audiences:
-        - **Humans** who want to understand, navigate, and contribute to the wiki
-        - **AI agents** who need to know which documents to load for a given task
-
-        This is NOT a documentation template — it is a META-DOCUMENT that describes how the
-        wiki itself works. Think of it as the README for the wiki system.
-    </purpose>
-
-    <template>
-        <header>
-            # Engineering Wiki
-
-            Living knowledge base for this codebase. Maintained by AI agents after each story
-            and by developers when making structural changes.
-
-            **For humans**: browse by subsystem, read system and pattern docs to understand how things work.
-            **For AI agents**: load the minimal set of docs needed for your current task — every token counts.
-        </header>
-
-        <directory-structure>
-            ## Directory Structure
-
-            ```
-            .docs/wiki/
-            |-- wiki-readme.md                          # This file — how to use the wiki
-            |-- system-wide/                            # Documents that span all subsystems
-            |   |-- system-structure.md                 # Physical layout, subsystem index, shared dirs
-            |   |-- system-architecture.md              # L1/L2 C4 views, core flows, tech stack
-            |   |-- testing-framework.md                # Test runner, patterns, conventions
-            |   |-- coding-standards.md                 # Language and paradigm-specific rules
-            |   `-- tech-debt-index.md                  # Roll-up of all known tech debt
-            `-- subsystems/
-                `-- [subsystem-name]/                    # One folder per subsystem
-                    |-- structure.md                     # File layout, "where to add code"
-                    |-- architecture.md                  # L3 components, internal flows, dependencies
-                    |-- systems/                         # WHAT exists — domain system docs
-                    |   `-- [system-name].md
-                    |-- patterns/                        # HOW to implement — reusable structural patterns
-                    |   `-- [pattern-name].md
-                    |-- cross-cutting/                   # Shared infrastructure spanning systems
-                    |   `-- [concern-name].md
-                    |-- guides/                          # Step-by-step implementation recipes
-                    |   `-- [task-name].md
-                    `-- decisions/                       # WHY — Architecture Decision Records
-                        `-- ADR-NNN-[slug].md
-            ```
-        </directory-structure>
-
-        <document-types>
-            ## Document Types
-
-            ### System-Wide Documents
-
-            | Document | Answers | Created By |
-            |----------|---------|------------|
-            | `system-structure.md` | What subsystems exist and where do they live? | `/ace:map-system` |
-            | `system-architecture.md` | What's the system design, tech stack, and core flows? | `/ace:map-system` |
-            | `testing-framework.md` | How do we test? Runner, patterns, conventions. | `/ace:map-system` |
-            | `coding-standards.md` | What are the mandatory code quality rules? | `/ace:init-coding-standards` |
-            | `tech-debt-index.md` | What known quality issues exist across the codebase? | `/ace:map-story` (auto) |
-
-            ### Subsystem Documents
-
-            | Document | Answers | Created By |
-            |----------|---------|------------|
-            | `structure.md` | Where do files live in this subsystem? Where do I add new code? | `/ace:map-subsystem` |
-            | `architecture.md` | What are the internal components, layers, and flows? | `/ace:map-subsystem` |
-
-            ### Knowledge Documents (per subsystem)
-
-            | Category | Answers | When to Create |
-            |----------|---------|----------------|
-            | `systems/` | How does this domain system work RIGHT NOW? | One doc per coherent domain capability (e.g., drawing system, order processing) |
-            | `patterns/` | How do I implement using this reusable pattern? | When a structural pattern appears in 2+ implementations |
-            | `cross-cutting/` | How does this shared infrastructure work? | For concerns spanning multiple domain systems (DI, events, registry) |
-            | `guides/` | How do I perform this recurring task end-to-end? | When a task is repeated (adding a new tool, endpoint, entity) |
-            | `decisions/` | Why was this significant choice made? | When a meaningful trade-off was evaluated and decided |
-        </document-types>
-
-        <how-to-use>
-            ## How to Use This Wiki
-
-            ### For Humans
-
-            **Understand a subsystem:**
-            1. Read `subsystems/[name]/architecture.md` — components, layers, internal flows
-            2. Read relevant `systems/*.md` — domain systems you care about
-            3. Follow cross-references to patterns and cross-cutting concerns
-
-            **Implement a new feature:**
-            1. Read `system-wide/coding-standards.md` — mandatory rules
-            2. Read the subsystem's `structure.md` — where to add files
-            3. Check `guides/` — there may be a step-by-step recipe for your task
-            4. Read relevant `patterns/` — follow established structural patterns
-            5. Check `decisions/` — respect past architectural decisions
-
-            **Debug or investigate:**
-            1. Start with the relevant `systems/*.md` — it has entry points, flows, and components
-            2. Follow the sequence diagrams to trace data flow
-            3. Check `cross-cutting/` for shared infrastructure behavior
-
-            ### For AI Agents
-
-            **Context loading strategy:**
-            - ALWAYS load system-wide docs first: `system-structure.md`, `system-architecture.md`, `coding-standards.md`, `testing-framework.md`
-            - Then load subsystem docs for the subsystem(s) you are modifying
-            - Load ONLY the `systems/`, `patterns/`, `cross-cutting/`, and `guides/` docs relevant to your task
-            - Check `decisions/` for ADRs that constrain your design choices
-            - Every token in your context window costs reasoning capacity — load less, reason better
-
-            **Finding the right docs:**
-            - Story files include a `## Relevant Wiki` section with curated doc references
-            - Each doc cross-references related docs via markdown links — follow them as needed
-            - `structure.md` → where files live; `architecture.md` → how things connect
-            - `systems/` → domain behavior; `patterns/` → structural recipes; `guides/` → task recipes
-        </how-to-use>
-
-        <how-to-create>
-            ## Creating New Wiki Documents
-
-            Wiki documents are primarily created and updated by AI agents (ace-wiki-mapper) through:
-            - `/ace:map-system` — system-wide documents
-            - `/ace:map-subsystem` — subsystem structure, architecture, and knowledge docs
-            - `/ace:map-story` — updates knowledge docs after story implementation
-
-            ### Manual Creation Guidelines
-
-            If creating a document manually, follow these rules:
-
-            **Naming:**
-            - Use kebab-case for all file names: `drawing-system.md`, `repository-pattern.md`
-            - Systems: name after the domain capability — `drawing-system.md`, `order-processing.md`
-            - Patterns: name after the pattern — `template-method-pattern.md`, `repository-pattern.md`
-            - Cross-cutting: name after the concern — `dependency-injection.md`, `event-system.md`
-            - Guides: name after the task — `adding-drawing-tool.md`, `adding-crud-endpoint.md`
-            - Decisions: `ADR-NNN-kebab-slug.md` — sequential numbering within the subsystem
-
-            **Content rules:**
-            - EXTREMELY SUCCINCT — every word must add value
-            - Bullet points over paragraphs
-            - Code references: `file-path:ClassName.methodName` — never line numbers
-            - All architecture diagrams MUST be mermaid (flowchart, classDiagram, sequenceDiagram)
-            - File trees: ASCII only (`|--` and backtick for last item)
-            - Inline code ONLY for interface/type contracts
-            - Cross-reference related docs with markdown links
-            - Every `systems/*.md` MUST have at least one mermaid sequenceDiagram
-
-            **Topic-scoped, not story-scoped:**
-            - Documents describe a CONCERN, not a story or sprint
-            - "How does the drawing system work?" — good
-            - "What story #19 implemented" — wrong (that goes in `.ace/artifacts/`)
-
-            **Create vs update decision:**
-            1. Does an existing doc already cover this topic? → UPDATE it
-            2. Could this be a new section in an existing doc? → Add the section
-            3. Any overlap with existing docs? → Merge into the existing doc
-            4. Genuinely new topic with no overlap? → CREATE a new doc
-        </how-to-create>
-
-        <keeping-current>
-            ## Keeping the Wiki Current
-
-            ### Automatic Updates
-
-            After each story implementation, `/ace:map-story` analyzes git changes and updates
-            the relevant knowledge documents. This is the primary mechanism for keeping the wiki
-            current.
-
-            ### Manual Update Triggers
-
-            **Update `system-structure.md` when:**
-            - New subsystem added, removed, or merged
-            - Shared directory added or removed
-            - Workspace configuration changed
-
-            **Update `system-architecture.md` when:**
-            - New subsystem or external integration added
-            - Communication pattern changed
-            - Tech stack changed
-
-            **Update `testing-framework.md` when:**
-            - Test runner or mocking approach changed
-            - Coverage requirements changed
-
-            **Update subsystem `structure.md` when:**
-            - Top-level directory added, renamed, or removed within the subsystem
-
-            **Update subsystem `architecture.md` when:**
-            - New architectural layer or component type introduced
-            - New inbound or outbound dependency added
-
-            **Update knowledge docs when:**
-            - `systems/` — new component, behavior, entry point, or integration point
-            - `patterns/` — new implementation added, pattern structure changed
-            - `cross-cutting/` — new registration, mechanism changed
-            - `guides/` — new step required, step order changed, reference implementation changed
-            - `decisions/` — NEVER edit accepted ADRs; create a new one that supersedes
-
-            ### Tech Debt
-
-            Tech debt items are tracked in individual `systems/` and `cross-cutting/` docs (## Tech Debt section)
-            and rolled up in `system-wide/tech-debt-index.md`. Items are removed when fixed.
-        </keeping-current>
-
-        <subsystem-index>
-            ## Subsystems
-
-            [POPULATE FROM system-structure.md — list each subsystem with link to its wiki folder]
-
-            | Subsystem | Wiki Path | Responsibility |
-            |-----------|-----------|----------------|
-            | [name] | [subsystems/name/](subsystems/name/) | [one-line responsibility] |
-        </subsystem-index>
-    </template>
-
-    <guidelines>
-
-        **This is a META-DOCUMENT, not a code documentation template.**
-        It describes the wiki system itself — its structure, conventions, and usage.
-        It does NOT contain code references, mermaid diagrams, or architectural content.
-
-        **Populating the template:**
-        - The Directory Structure section is FIXED — it describes the standard wiki layout.
-          Do NOT customize it per project. It shows the canonical structure.
-        - The Document Types tables are FIXED — they describe what each document type is.
-        - The Subsystems table at the bottom MUST be populated from `system-structure.md`
-          (the subsystem index). If `system-structure.md` doesn't exist yet, leave the table
-          with placeholder rows and a note to populate after `/ace:map-system`.
-        - All wiki paths in the Subsystems table should be relative links from the wiki root.
-
-        **Tone:**
-        - Direct and practical — this is a reference, not a tutorial
-        - Written for two audiences in parallel: humans and AI agents
-        - Short sentences, bullet points, tables over prose
-        - No filler, no motivational text, no history
-
-        **What does NOT belong here:**
-        - Actual code documentation (that lives in the wiki docs themselves)
-        - Project-specific architecture details (that's system-architecture.md)
-        - Process details about ACE workflows (that's internal to the tool)
-        - Story or feature information
-        - Revision history
-
-    </guidelines>
-
-    <evolution>
-
-        This document is MOSTLY STABLE — it describes the wiki system, which rarely changes.
-
-        **Update triggers:**
-        - New document type added to the wiki system (e.g., a new knowledge category)
-        - New subsystem mapped (update the Subsystems table)
-        - Subsystem removed or renamed (update the Subsystems table)
-        - Wiki conventions changed (naming rules, diagram rules, reference format)
-
-        **NOT an update trigger:**
-        - New documents created within existing categories
-        - Content updates to any wiki document
-        - New stories, features, or sprints
-        - Changes to ACE tool internals
-
-        **Update rules:**
-        - UPDATE the Subsystems table when subsystems are added/removed
-        - The rest of the document should rarely need changes
-        - If the wiki structure itself evolves (new folders, new doc types), update the
-          Directory Structure and Document Types sections
-
-    </evolution>
-
-</wiki-readme>

package/commands/ace/execute-story.md

@@ -1,137 +0,0 @@
----
-name: ace:execute-story
-description: Execute a fully-planned story — loads AC + Technical Solution, creates execution plan via Plan Mode, implements (solo or agent teams), runs code review, updates state, and triggers wiki mapping
-argument-hint: "story=<file-path|github-url> [--agent-teams-off]"
-allowed-tools:
-  - Read
-  - Bash
-  - Write
-  - Edit
-  - AskUserQuestion
-  - Glob
-  - Grep
-  - Agent
-  - EnterPlanMode
-  - ExitPlanMode
----
-
-```xml
-<command>
-
-    <execution-time>
-        <runs-after>
-            <trigger>After /ace:plan-story — once a story has AC + Technical Solution</trigger>
-            <trigger>Anytime — to execute a fully-planned story specification</trigger>
-        </runs-after>
-        <use-when>
-            <condition>A story has both Acceptance Criteria AND Technical Solution sections</condition>
-            <condition>Story status is "Refined" (ready for implementation)</condition>
-        </use-when>
-    </execution-time>
-
-    <input>
-        <flags>
-            <flag name="--agent-teams-off">
-                Force solo execution mode regardless of agent_teams setting.
-                Overrides the agent_teams flag in settings.json.
-                Use when you want single-context execution even if teams are enabled.
-            </flag>
-        </flags>
-
-        <parameters>
-            <required>
-                <param name="story" type="file | github-url">
-                    Story source — can be either:
-                    - **File path**: Path to a fully-planned story markdown file
-                      (must have AC + Technical Solution sections)
-                    - **GitHub URL or issue number**: GitHub story reference
-                    Must be a valid, accessible file or GitHub issue.
-                    The story MUST have been through /ace:plan-story (has AC + Technical Solution).
-                </param>
-            </required>
-        </parameters>
-    </input>
-
-    <execution-context>
-        <execute-story-workflow>@~/.claude/agile-context-engineering/workflows/execute-story.xml</execute-story-workflow>
-        <story-template>@~/.claude/agile-context-engineering/templates/product/story.xml</story-template>
-        <questioning>@~/.claude/agile-context-engineering/utils/questioning.xml</questioning>
-        <ui-formatting>@~/.claude/agile-context-engineering/utils/ui-formatting.md</ui-formatting>
-    </execution-context>
-
-    <output>
-        <objective>
-            Take a fully-planned story (with AC + Technical Solution) and:
-            1. Create an execution plan via Claude Code Plan Mode
-            2. Execute the plan — solo or with Agent Teams
-            3. Run code review (3-level verification, anti-pattern detection, coding standards)
-            4. Present results to user for verification/approval
-            5. Commit implementation (single commit after approval)
-            6. Update state: story file, feature file, product backlog, GitHub
-            7. Trigger wiki mapping (background) with tech debt integration
-
-            Two execution modes:
-            - **Solo Mode** (default or --agent-teams-off): Single context, plan mode → execute
-            - **Agent Teams Mode** (when enabled + plan recommends): Lead + teammates for parallel work
-        </objective>
-
-        <artifacts>
-            Story file updated with Summary &amp; State section and Wiki Updates section.
-            Feature file updated with story status.
-            Product backlog updated with story (and possibly feature) status.
-            Wiki documents updated/created based on implementation changes.
-        </artifacts>
-    </output>
-
-    <process>
-        **STRICT WORKFLOW EXECUTION — Follow the execute-story workflow STEP BY STEP.
-        Do NOT skip steps. Do NOT improvise. Do NOT start reading code or planning
-        until step 1 (init &amp; validate) is fully complete with the init command output parsed.**
-
-        Execute the execute-story workflow from
-        `@~/.claude/agile-context-engineering/workflows/execute-story.xml` end-to-end.
-
-        **MANDATORY FIRST ACTION: Run the init command (step 1.2) BEFORE doing anything else.
-        Do NOT read the story file manually. Do NOT explore the codebase. Do NOT start planning.
-        The init command validates the story and provides all paths and context needed.**
-
-        **CRITICAL REQUIREMENTS:**
-        - Story MUST have Acceptance Criteria — STOP if missing
-        - Story MUST have Technical Solution — STOP if missing
-        - NO intermediary commits during implementation
-        - ONE single commit per story after user approval (code + state + docs)
-        - Code review is MANDATORY — blockers must be fixed before approval
-        - Coding standards violations are BLOCKERS, not warnings
-        - Dead code and backwards-compatible shims must be DELETED
-    </process>
-
-    <example-usage>
-        ```
-        # Execute a story from a file path
-        /ace:execute-story \
-          story=.ace/artifacts/product/e1-auth/f3-oauth/s1-buttons/s1-buttons.md
-
-        # Execute from a GitHub issue
-        /ace:execute-story \
-          story=https://github.com/owner/repo/issues/95
-
-        # Force solo mode (no agent teams)
-        /ace:execute-story \
-          story=.ace/artifacts/product/e1-auth/f3-oauth/s1-buttons/s1-buttons.md \
-          --agent-teams-off
-
-        # With just an issue number
-        /ace:execute-story story=#95
-        ```
-    </example-usage>
-
-    <next-steps>
-        **After this command:**
-        - `/ace:execute-story story=...` — Execute the next story in the feature
-        - `/ace:review-story story=...` — Re-run code review (standalone)
-        - `/ace:plan-story story=...` — Plan the next story
-        - `/ace:help` — Check project status
-    </next-steps>
-
-</command>
-```

package/commands/ace/help.md

@@ -1,93 +0,0 @@
----
-name: ace:help
-description: Check project initialization status and suggest next steps
-argument-hint: ""
-allowed-tools:
-  - Read
-  - Bash
-  - Write
-  - AskUserQuestion
----
-
-```xml
-<command>
-
-    <execution-time>
-        <runs-after>
-            <trigger>At any time — to check which ACE documents exist and what to do next</trigger>
-            <trigger>At the start of a new project — to see the initialization checklist</trigger>
-        </runs-after>
-        <use-when>
-            <condition>Starting a new project and want to see what needs to be set up</condition>
-            <condition>Returning to a project and want to check initialization status</condition>
-            <condition>Unsure which ACE command to run next</condition>
-        </use-when>
-    </execution-time>
-
-    <input>
-        <flags>
-        </flags>
-
-        <parameters>
-            <required>
-            </required>
-
-            <optional>
-            </optional>
-        </parameters>
-    </input>
-
-    <execution-context>
-        <help-workflow>@~/.claude/agile-context-engineering/workflows/help.xml</help-workflow>
-        <questioning>@~/.claude/agile-context-engineering/utils/questioning.xml</questioning>
-        <ui-formatting>@~/.claude/agile-context-engineering/utils/ui-formatting.md</ui-formatting>
-    </execution-context>
-
-    <output>
-        <objective>
-            Detect which ACE documents exist (product vision, system architecture, system structure,
-            coding standards, testing framework). Display a status dashboard showing what's done
-            and what's missing. Suggest the next command to run based on gaps.
-        </objective>
-
-        <artifacts>
-            - .ace/settings.json (created on first run if missing)
-        </artifacts>
-    </output>
-
-    <process>
-        Execute the help workflow from
-        `@~/.claude/agile-context-engineering/workflows/help.xml` end-to-end.
-        This is a lightweight state-check and routing workflow.
-
-        CRITICAL MANDATORY STEP — DO NOT SKIP:
-        Before displaying the status dashboard, you MUST run:
-        ```bash
-        node ~/.claude/agile-context-engineering/src/ace-tools.js sync-agent-teams --raw
-        ```
-        Then you MUST use `AskUserQuestion` to ask the user whether they want to
-        enable or disable Claude Code Agent Teams (experimental feature).
-        This step is NOT optional. You MUST present this question every time.
-
-        When the user chooses to enable or disable Agent Teams, you MUST run the
-        bash command — NEVER directly edit .ace/settings.json or .claude/settings.json:
-        ```bash
-        node ~/.claude/agile-context-engineering/src/ace-tools.js write-agent-teams true
-        ```
-        or
-        ```bash
-        node ~/.claude/agile-context-engineering/src/ace-tools.js write-agent-teams false
-        ```
-        The write-agent-teams command updates BOTH .ace/settings.json AND .claude/settings.json.
-        Direct file edits will cause the two files to go out of sync.
-    </process>
-
-    <next-steps>
-        **Specialized commands for each document:**
-        - `/ace:plan-product-vision` — Create or update the product vision
-        - `/ace:map-system` — Map codebase structure, architecture, and testing framework
-        - `/ace:init-coding-standards` — Generate tailored coding standards
-    </next-steps>
-
-</command>
-```

package/commands/ace/init-coding-standards.md

@@ -1,83 +0,0 @@
----
-name: ace:init-coding-standards
-description: Generate a tailored coding-standards.md through codebase detection and user interview
-argument-hint: "[optional: context='existing standards doc or notes to build on']"
-allowed-tools:
-  - Read
-  - Bash
-  - Glob
-  - Grep
-  - Write
-  - Task
-  - AskUserQuestion
----
-
-```xml
-<command>
-
-    <execution-time>
-        <runs-after>
-            <trigger>During /ace:help — as part of initial project setup</trigger>
-            <trigger>After /ace:map-system — once codebase is mapped, add prescriptive standards</trigger>
-            <trigger>Anytime — to create or refresh coding standards for a project</trigger>
-        </runs-after>
-        <use-when>
-            <condition>Starting a new project and want to establish coding standards upfront (greenfield or brownfield)</condition>
-            <condition>Onboarding AI agents to an existing codebase (prevents common AI mistakes)</condition>
-            <condition>Current coding standards are outdated or missing</condition>
-            <condition>Team has pain points with AI-generated code quality</condition>
-        </use-when>
-    </execution-time>
-
-    <input>
-        <flags>
-        </flags>
-
-        <parameters>
-            <required>
-            </required>
-
-            <optional>
-                <param name="context" type="file | text">
-                    Existing coding standards document, style guide, or notes
-                    to use as a starting point. Will be refined through the interview process.
-                </param>
-            </optional>
-        </parameters>
-    </input>
-
-    <execution-context>
-        <init-coding-standards-workflow>@~/.claude/agile-context-engineering/workflows/init-coding-standards.xml</init-coding-standards-workflow>
-        <coding-standards-template>@~/.claude/agile-context-engineering/templates/wiki/coding-standards.xml</coding-standards-template>
-        <questioning>@~/.claude/agile-context-engineering/utils/questioning.xml</questioning>
-        <ui-formatting>@~/.claude/agile-context-engineering/utils/ui-formatting.md</ui-formatting>
-    </execution-context>
-
-    <output>
-        <objective>
-            Detect the project's language, paradigm, and frameworks (brownfield) or gather
-            this from the user (greenfield). Interview the user about their coding philosophy
-            and pain points. Generate a tailored, prescriptive coding-standards.md that prevents
-            common AI and developer mistakes.
-        </objective>
-
-        <artifacts>
-            .docs/wiki/system-wide/coding-standards.md
-        </artifacts>
-    </output>
-
-    <process>
-        Execute the init-coding-standards workflow from
-        `@~/.claude/agile-context-engineering/workflows/init-coding-standards.xml` end-to-end.
-        Preserve all workflow gates (validation, approvals, commits).
-    </process>
-
-    <next-steps>
-        **After this command:**
-        - `/ace:map-system` — Map codebase structure and architecture
-        - `/ace:help` — Check project initialization status and next steps
-        - Review and edit `.docs/wiki/system-wide/coding-standards.md` anytime
-    </next-steps>
-
-</command>
-```