@axis-bootstrap/cli 0.1.0 → 0.1.2

package/package.json

@@ -1,8 +1,17 @@
 {
   "name": "@axis-bootstrap/cli",
-  "version": "0.1.0",
+  "version": "0.1.2",
   "description": "AXIS — Harness-first scaffolding & SPDD pipeline CLI for AI-augmented projects",
   "type": "module",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/jhonymiler/AXIS-Framework.git",
+    "directory": "cli"
+  },
+  "homepage": "https://github.com/jhonymiler/AXIS-Framework#readme",
+  "bugs": {
+    "url": "https://github.com/jhonymiler/AXIS-Framework/issues"
+  },
   "publishConfig": {
     "access": "public"
   },
@@ -39,4 +48,4 @@
     "@clack/prompts": "^0.7.0",
     "picocolors": "^1.0.1"
   }
-}
+}

package/templates/bootstrap-skill/PROMPT-TEMPLATE.md

@@ -18,6 +18,7 @@ target-project/
 │   ├── rules/                                     (3-7 rules — if applicable)
 │   │   ├── code-style.md
 │   │   ├── architecture-patterns.md
+│   │   ├── workflow.md                            (PM tool + commit/branch/PR standards — if Phase 1 Block 4 produced answers)
 │   │   └── ...
 │   └── docs/
 │       ├── architecture.md                        (if software)
@@ -58,8 +59,9 @@ Order (consultation frequency, not logical importance):
 4. Architecture in table (components + responsibility)
 5. Design principles (3-7 bullets with rationale)
 6. Code conventions (summary — details in rules)
-7. Available skills (table with when to use)
-8. Links to docs and references
+7. Workflow & Tools (PM tool, branch/commit/PR standards — details in `rules/workflow.md`)
+8. Available skills (table with when to use)
+9. Links to docs and references
 
 **Size:** 100-180 lines. Below 100 is superficial; above 200 loses focus.
 

package/templates/bootstrap-skill/references/PHASE-1-DISCOVERY.md

@@ -118,3 +118,46 @@ Apply principles from [UNIVERSAL-MAP.md](UNIVERSAL-MAP.md) and adapt. Ultimately
 14. What level of validation is acceptable? (vibe-check, human review, automated gates, all)
 15. Is there a history of problems the framework should prevent? (e.g., "we lose context whenever the dev changes", "AI responses diverge between IDEs")
 ```
+
+---
+
+## Block 4 — Collaboration & Governance
+
+Apply whenever the project uses version control or any task tracker (most projects). Skip individual questions that visibly don't apply (e.g., solo project with no PR flow).
+
+```text
+16. Task / project management tool? (Jira, Linear, GitHub Projects, Trello, Asana, ClickUp, Notion, none)
+    - If applicable: board / project ID and ticket prefix (e.g., PROJ-123, ENG-456)
+    - Workflow states used (To Do → In Progress → Review → Done) or custom?
+    - Where to find the board (URL or MCP reference)?
+
+17. Commit message standard?
+    - Convention: Conventional Commits (feat:, fix:, chore:, ...), Gitmoji, free-form, other
+    - Ticket ID required in subject or trailer? Format example?
+    - Sign-off (DCO), GPG signing, or Co-authored-by trailers required?
+
+18. Branch model & naming?
+    - Main branch name (main / master / trunk)
+    - Naming pattern (feature/, fix/, hotfix/, chore/, release/, <user>/<slug>)
+    - Strategy: trunk-based, GitHub Flow, Git Flow, release branches
+    - Direct push to main allowed, or PR-only? Branch protection rules?
+
+19. Pull Request rules?
+    - PR title format (Conventional, ticket prefix, free)
+    - PR template / required sections (summary, test plan, screenshots, rollback)
+    - Minimum approvals, CODEOWNERS, required CI checks
+    - Merge strategy: squash, merge commit, rebase-and-merge
+    - Auto-delete branch after merge? Linear history enforced?
+
+20. Task / story creation standards?
+    - Required fields (description, AC, story points, epic, labels, components)
+    - Definition of Ready / Definition of Done templates?
+    - Estimation system (story points, t-shirt sizes, hours, none)?
+
+21. Release & versioning?
+    - Versioning scheme (SemVer, CalVer, none)
+    - Changelog (Keep a Changelog, auto-generated from commits, none)
+    - Release cadence (continuous, sprint, scheduled)
+```
+
+If the project does not use git or any tracker (rare — usually a solo content or research draft), skip this block entirely and note it in the Project Profile.

package/templates/bootstrap-skill/references/PHASE-2-SPEC.md

@@ -43,8 +43,9 @@ Use the template from [TEMPLATES.md → INSTRUCTIONS.md](TEMPLATES.md#instructio
 4. **Architecture** (table: component → responsibility → technology → location)
 5. **Design Principles** (3-7 bullets with short rationale)
 6. **Conventions** (summary — details in rules)
-7. **Available Skills** (table: skill → when to use)
-8. **Links** (to detailed docs)
+7. **Workflow & Tools** (task tracker, branch model, commit/PR standards — details in `rules/workflow.md`). Skip only if Phase 1 Block 4 was fully skipped.
+8. **Available Skills** (table: skill → when to use)
+9. **Links** (to detailed docs)
 
 **Target size:** 100-180 lines. Below 100 is superficial; above 200 loses focus.
 
@@ -133,9 +134,12 @@ For software projects, create 3-7 rules in `.ai/rules/`. Use template [Rule in T
 ├── architecture-patterns.md (DI, modules, framework patterns)
 ├── database.md              (ORM, migrations, queries)
 ├── testing.md               (test structure, mocks)
-└── cli.md                   (commands and scripts)
+├── cli.md                   (commands and scripts)
+└── workflow.md              (PM tool, branch model, commit & PR standards — populated from Phase 1 Block 4)
 ```
 
+**`workflow.md`** is created whenever Phase 1 Block 4 produced answers (PM tool, commit convention, branch model, PR rules, task/release standards). Even non-software projects that use git benefit from it — keep only the sections that apply. Template in [TEMPLATES.md → workflow.md](TEMPLATES.md#workflowmd-rule).
+
 **Frontmatter for scope:**
 
 ```yaml

package/templates/bootstrap-skill/references/PHASE-5-VALIDATION.md

@@ -29,6 +29,8 @@ This phase also runs in standalone mode when the user asks to **audit an existin
 [ ] Each SKILL.md has frontmatter with `name` and `description`
 [ ] Each `description` has 2-4 lines and mentions trigger terms
 [ ] For software projects: at least 3 rules in .ai/rules/ with `applyTo`
+[ ] If Phase 1 Block 4 was answered: .ai/rules/workflow.md exists with the populated sections (PM tool, commits, branches, PRs)
+[ ] INSTRUCTIONS.md has a "Workflow & Tools" section pointing to rules/workflow.md (or block 4 was explicitly skipped)
 [ ] At least 1 stub in .ai/docs/ (architecture.md, glossary.md, or equivalent)
 [ ] .ai/CONVENTIONS.md exists and contains symlink map
 [ ] .ai/docs/STATE.md exists with the 6 mandatory sections

package/templates/bootstrap-skill/references/QUICKSTART.md

@@ -24,6 +24,7 @@ Answer mentally or paste the answers to the agent:
 2. **Main stack/tools?** (or "non-technical" if content/research)
 3. **Which IDE(s) do you use?** (Claude Code / Cursor / Windsurf / Copilot — mark all)
 4. **Is there anything the agent should NEVER do?** (e.g., push directly to main, delete production data)
+5. **Workflow basics** (1 line each — skip what doesn't apply): task tracker (Jira/Linear/GitHub/none) + ticket prefix; commit standard (Conventional / free); branch pattern (e.g., `feature/<ticket>-<slug>`); PR rules (approvals, CI, merge strategy). For the full version, see Block 4 of [PHASE-1-DISCOVERY.md](PHASE-1-DISCOVERY.md#block-4--collaboration--governance).
 
 ---
 

package/templates/bootstrap-skill/references/TEMPLATES.md

@@ -50,6 +50,16 @@ Summary here; details in [.ai/rules/](rules/):
 - Error handling: <rule>
 - Tests: <rule>
 
+## Workflow & Tools
+
+Summary here; full standards in [.ai/rules/workflow.md](rules/workflow.md):
+
+- **Task tracker:** <e.g., Jira board ENG, tickets ENG-XXX>
+- **Commits:** <e.g., Conventional Commits with ticket trailer>
+- **Branches:** <e.g., feature/<ticket>-<slug>, PR-only into main>
+- **PRs:** <e.g., 1 approval + green CI, squash merge>
+- **Versioning:** <e.g., SemVer, changelog auto-generated>
+
 ## Available Skills
 
 | Skill                                  | When to use   |
@@ -137,6 +147,77 @@ paths:
 
 ---
 
+## workflow.md (rule)
+
+Populated from Phase 1 Block 4. Keep only the sections that apply — empty sections add noise.
+
+```markdown
+---
+applyTo: "**"
+---
+
+# Workflow & Governance
+
+> Source of truth for branch, commit, PR, task, and release standards. The agent must follow this without being reminded.
+
+## Task / Project Management
+
+- **Tool:** <Jira | Linear | GitHub Projects | Trello | Asana | ClickUp | Notion | none>
+- **Board / project:** <e.g., Jira board ENG, URL or MCP reference>
+- **Ticket prefix:** <e.g., ENG-XXX, PROJ-XXX>
+- **Workflow states:** <e.g., Backlog → Ready → In Progress → Review → Done>
+- **Required fields when creating a task:** <description, AC, story points, epic, labels>
+- **Definition of Ready / Done:** <link or inline checklist>
+
+## Commit Messages
+
+- **Convention:** <Conventional Commits | Gitmoji | free-form | other>
+- **Format example:**
+  ```
+  feat(api): add idempotency key validation [ENG-1234]
+  ```
+- **Ticket ID:** <required in subject | required as trailer | optional>
+- **Sign-off / GPG / Co-authored-by:** <DCO sign-off required | GPG required | Co-authored-by trailers for pairing>
+- **Length:** subject ≤ 72 chars; body wrapped at 100; imperative mood.
+
+## Branches
+
+- **Main branch:** <main | master | trunk>
+- **Naming pattern:** `<type>/<ticket>-<slug>` — examples:
+  - `feature/ENG-1234-add-webhook`
+  - `fix/ENG-1310-null-pointer-checkout`
+  - `chore/upgrade-node-20`
+- **Allowed prefixes:** <feature/, fix/, hotfix/, chore/, release/, docs/>
+- **Strategy:** <trunk-based | GitHub Flow | Git Flow | release branches>
+- **Branch protection:** <PR-only into main | required status checks | linear history | no force-push>
+
+## Pull Requests
+
+- **Title format:** <Conventional, ticket prefix in title, free>
+- **Template / required sections:** Summary, Changes, Test Plan, Screenshots, Rollback, Linked Issues
+- **Approvals required:** <N approvals, CODEOWNERS for paths X/Y>
+- **Required CI checks:** <build, unit tests, integration tests, lint, type-check>
+- **Merge strategy:** <squash | merge commit | rebase-and-merge>
+- **Post-merge:** <auto-delete branch | auto-deploy to staging>
+
+## Releases & Versioning
+
+- **Scheme:** <SemVer (MAJOR.MINOR.PATCH) | CalVer | none>
+- **Changelog:** <Keep a Changelog | auto-generated from Conventional Commits | none>
+- **Cadence:** <continuous | weekly | sprint | scheduled>
+- **Tagging:** <v1.2.3 | release/2026-05 | none>
+
+## Agent Behavior Rules
+
+- Never push directly to `<main>` — always open a PR.
+- Always include the ticket ID in the commit subject/trailer when the change traces to a ticket.
+- Branch name must match the pattern above before the first commit; fix it locally before pushing.
+- PR description must reference the ticket and include a test plan; do not request review without these.
+- Do not merge a PR without the required approvals and green CI — even if "obviously safe".
+```
+
+---
+
 ## STATE.md
 
 ```markdown