kotonoha 0.1.1 → 0.1.4

package/skills/tech-writer/references/doctypes/migration-plan.md

@@ -0,0 +1,63 @@
+# Migration plan type
+
+A migration plan defines how data, users, integrations, and business
+processes move from a current state to a target state with measurable
+validation, controlled downtime, and a tested rollback path.
+
+## Target reader
+
+Migration leads, application and data engineers, business owners, operators,
+support teams, security reviewers, and Go/No-Go approvers.
+
+## Settle before writing
+
+- The current and target states and complete migration inventory
+- Allowed downtime, data-loss tolerance, and business continuity needs
+- Migration approach, waves, dependencies, and change-freeze conditions
+- Reconciliation and business-acceptance criteria
+- Go/No-Go and rollback authority, triggers, and deadlines
+- Rehearsal evidence, communication needs, and post-migration support
+
+## Responsibility boundary
+
+Own the executable transition plan and its decisions. Link to implementation
+scripts rather than embedding large programs. Do not claim rollback is
+possible unless the plan states how post-cutover writes and data consistency
+will be handled.
+
+The migration section in `system-design` is sufficient for describing the
+chosen transition architecture. Use a standalone `migration-plan` when the
+cutover needs rehearsals, a timed procedure, business communications,
+Go/No-Go gates, reconciliation evidence, or separate approval. When both
+exist, the migration plan is authoritative for execution and the system
+design summarizes the strategy and links to it.
+
+## Template
+
+Start from `assets/templates/migration-plan.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Agreement target, current and target states, scope, and constraints
+2. Inventory, dependencies, mappings, transformation, and migration method
+3. Roles, rehearsals, readiness, and timed production procedure
+4. Reconciliation, Go/No-Go gates, rollback, and business continuity
+5. Security, communication, stabilization, decommissioning, and approval
+
+## Checklist
+
+- [ ] Are all data, configuration, identities, integrations, and business
+      processes inventoried with owners and dependencies?
+- [ ] Are mapping, transformation, default, rejection, retry, and idempotency
+      rules explicit?
+- [ ] Have full-scale timing, validation, and rollback been rehearsed?
+- [ ] Are start, cutover, reopen, Go/No-Go, and rollback conditions objective?
+- [ ] Do reconciliation checks cover counts, aggregates, referential
+      integrity, and business scenarios?
+- [ ] Does rollback address writes made after cutover and its last safe time?
+- [ ] Are downtime communications, alternative operations, support, security,
+      temporary access, and evidence covered?
+- [ ] Are stabilization, cleanup, old-system retention, and decommissioning
+      conditions defined?

package/skills/tech-writer/references/doctypes/operations-runbook.md

@@ -0,0 +1,63 @@
+# Operations design and runbook type
+
+An operations design and runbook makes a production service observable,
+changeable, recoverable, and supportable. It combines stable operating
+policies with executable procedures for routine work and incidents.
+
+## Target reader
+
+Service owners, on-call engineers, operators, support staff, security teams,
+change approvers, and incident commanders.
+
+## Settle before writing
+
+- The service boundary, owners, dependencies, and operating hours
+- SLI, SLO, alert, capacity, backup, RTO, and RPO targets
+- On-call, escalation, change, and incident authority
+- Access requirements and safety constraints for operational actions
+- The symptoms and failure scenarios that require executable runbooks
+- Review, exercise, and expiration frequency
+
+## Responsibility boundary
+
+Write steps that an authorized operator can execute and verify. Link to
+automation where it exists, but preserve preconditions, safety checks,
+expected results, escalation, and recovery behavior. Never include secret
+values or bypass access and change controls.
+
+The operations section in `system-design` is sufficient for architectural
+operability decisions. Use a standalone `operations-runbook` when on-call
+staff need executable procedures, alerts, escalation, exercises, or a review
+cycle independent of the system design. When both exist, the runbook is
+authoritative for live operations and the system design links to its current
+approved version.
+
+## Template
+
+Start from `assets/templates/operations-runbook.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Service scope, dependencies, levels, owners, and escalation
+2. Observability, alerts, routine work, and capacity management
+3. Incident severity, common initial response, and symptom runbooks
+4. Start, stop, restore, security, change, and rollback procedures
+5. Disaster recovery, business continuity, risks, exercises, and review
+
+## Checklist
+
+- [ ] Can an unfamiliar authorized operator identify the service, owner,
+      dependencies, dashboards, communication channels, and impact?
+- [ ] Are SLI/SLO calculations, alert conditions, suppression, and test
+      frequency specified?
+- [ ] Does every procedure state preconditions, safety limits, steps,
+      expected results, evidence, escalation, and recovery?
+- [ ] Are backup restoration, RTO/RPO, disaster recovery, and exercises
+      executable and owned?
+- [ ] Are access, secret, certificate, vulnerability, audit, and security
+      incident operations covered without exposing secret values?
+- [ ] Are releases, emergency changes, rollback, and post-change checks clear?
+- [ ] Are capacity, cost, routine maintenance, review dates, and stale
+      runbook detection addressed?

package/skills/tech-writer/references/doctypes/requirements-definition.md

@@ -0,0 +1,61 @@
+# Requirements definition type
+
+A requirements definition establishes agreement on what outcomes, scope,
+capabilities, quality levels, and acceptance conditions a system must
+satisfy. It describes the required behavior and measurable constraints
+without prematurely prescribing the implementation architecture.
+
+## Target reader
+
+Business owners, product owners, users, architects, delivery teams,
+operators, security reviewers, and approvers who must agree on what will be
+built and how acceptance will be judged.
+
+## Settle before writing
+
+- The business problem, target users, and measurable outcome
+- In-scope and out-of-scope business processes, systems, and data
+- Requirement priorities and the authority that resolves conflicts
+- Constraints covering budget, schedule, law, policy, and existing systems
+- Measurable acceptance conditions for functional and non-functional needs
+- The identifier or naming convention used for traceability
+
+## Responsibility boundary
+
+State what the system must achieve and the constraints it must meet. Do not
+turn preferred products, component layouts, database schemas, or deployment
+topologies into requirements unless they are genuine externally imposed
+constraints. Put implementation choices in a system design document and
+link them back to requirement IDs.
+
+## Template
+
+Start from `assets/templates/requirements-definition.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Agreement target, background, problem, purpose, and success measures
+2. Scope, stakeholders, assumptions, and constraints
+3. Business flow, business rules, and prioritized functional requirements
+4. Measurable non-functional, data, and external-interface requirements
+5. Migration, operation, acceptance, and traceability
+6. Risks, open questions, approval, and change history
+
+## Checklist
+
+- [ ] Are purpose, scope, exclusions, stakeholders, assumptions, and
+      constraints explicit?
+- [ ] Does every requirement have a stable ID, priority, and independently
+      verifiable acceptance condition?
+- [ ] Are non-functional requirements measurable under stated conditions?
+- [ ] Are data ownership, classification, retention, quality, and deletion
+      requirements covered?
+- [ ] Are external interfaces, migration, operations, and failure handling
+      included where applicable?
+- [ ] Can each requirement be traced to a problem or objective and forward
+      to an acceptance test and design or implementation artifact?
+- [ ] Are implementation preferences separated from actual constraints?
+- [ ] Are unresolved items owned and time-bound, with approval and change
+      history recorded?

package/skills/tech-writer/references/doctypes/rfi.md

@@ -0,0 +1,43 @@
+# Request for information (RFI) type
+
+An RFI gathers market, vendor, product, feasibility, and indicative pricing
+information before requirements or procurement strategy are final. It must
+not read like an award decision or demand proposal-level effort.
+
+## Target reader
+
+Potential suppliers preparing an overview-level response, and the internal
+team using those responses to refine requirements and decide whether to
+proceed to an RFP.
+
+## Settle before writing
+
+- The unknowns the market research must resolve
+- The respondent population and distribution/confidentiality level
+- The current-environment details safe to disclose before an NDA
+- The response schedule and single source of truth for dates
+- The intended next step, while avoiding any promise to issue an RFP
+
+## Template
+
+Start from `assets/templates/rfi.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Purpose, non-procurement disclaimer, and current context
+2. Overview-level company, product, architecture, and security questions
+3. Indicative implementation, support, roadmap, and pricing information
+4. Response format, authoritative schedule, and handling conditions
+5. Respondent checklist
+
+## Checklist
+
+- [ ] Does the document state that responses are not scored or ranked?
+- [ ] Does it request overview-level information rather than detailed design?
+- [ ] Are indicative prices clearly non-binding?
+- [ ] Are roadmap, constraints, and unsupported capabilities reportable?
+- [ ] Is sensitive configuration moved to an NDA-controlled annex?
+- [ ] Is the schedule the single source of truth for dates?
+- [ ] Does the disclaimer avoid promising procurement or an RFP?

package/skills/tech-writer/references/doctypes/rfp.md

@@ -0,0 +1,46 @@
+# Request for proposal (RFP) type
+
+An RFP asks qualified suppliers for comparable, evaluable, and
+contract-ready proposals against explicit requirements, acceptance criteria,
+commercial terms, and a disclosed evaluation method.
+
+## Target reader
+
+Suppliers deciding whether and how to bid, evaluators scoring proposals, and
+procurement or legal reviewers preparing the resulting contract.
+
+## Settle before writing
+
+- Procurement scope, exclusions, budget model, and contract term
+- Must/Should/Could requirements and the consequence of failing a Must
+- Measurable acceptance criteria and payment milestones
+- Bidder eligibility, security, compliance, and subcontracting conditions
+- TCO period, price-scoring formula, category weights, and pass thresholds
+- The authoritative procurement schedule and confidentiality controls
+
+## Template
+
+Start from `assets/templates/rfp.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Procurement purpose, scope, exclusions, and current environment
+2. Functional, non-functional, security, migration, and support requirements
+3. Bidder eligibility, deliverables, acceptance, and payment
+4. Requested proposal contents, implementation schedule, and TCO pricing
+5. Evaluation formula, submission process, authoritative schedule, and terms
+6. Bidder submission checklist
+
+## Checklist
+
+- [ ] Can every functional and non-functional requirement be answered in a
+      structured, comparable format?
+- [ ] Are Must failures and bidder disqualification rules explicit?
+- [ ] Are deliverables linked to acceptance and payment conditions?
+- [ ] Are bidder eligibility and conflict/subcontractor disclosures covered?
+- [ ] Can all price rows be normalized into the stated TCO period?
+- [ ] Is the scoring formula reproducible by independent evaluators?
+- [ ] Is sensitive environment detail isolated in an NDA-controlled annex?
+- [ ] Is the schedule the single source of truth for all procurement dates?

package/skills/tech-writer/references/doctypes/security-design.md

@@ -0,0 +1,71 @@
+# Security design and threat model type
+
+A security design and threat model identifies protected assets, trust
+boundaries, threats, controls, verification, and residual risk. It turns
+security and compliance requirements into reviewable implementation and
+operational decisions.
+
+## Target reader
+
+Architects, developers, platform and security engineers, privacy and
+compliance reviewers, operators, and accountable risk acceptors.
+
+## Settle before writing
+
+- System scope, architecture, data flows, trust boundaries, and environments
+- Assets, owners, sensitivity, retention, and regulatory obligations
+- Identities, roles, administrative paths, and external dependencies
+- Threat-model method and risk-rating approach
+- Security testing, exception, and residual-risk acceptance authority
+- The approved requirements and system-design baselines
+
+## Responsibility boundary
+
+Document security decisions and trace threats to controls and tests. Do not
+include credentials, private keys, exploitable production details, or
+instructions that bypass controls. Vulnerability findings needing restricted
+handling belong in the repository's approved security-reporting channel.
+
+The security section in `system-design` is sufficient for an integrated
+architecture summary. Use a standalone `security-design` when threat
+modeling, control ownership, compliance evidence, exceptions, or risk
+acceptance needs independent review. When both exist, the security design is
+authoritative for threats, controls, and residual risk.
+
+This document owns security-test intent by tracing requirements and threats
+to controls and planned tests, including the expected environment class and
+required evidence type. The `test-plan` owns actual execution environments,
+schedule, release gates, results, and evidence storage; copy the security
+test IDs, threat IDs, and control IDs into its traceability table.
+
+## Template
+
+Start from `assets/templates/security-design.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Scope, requirements, assets, data classification, and architecture
+2. Trust boundaries, identity, authentication, authorization, and threats
+3. Preventive, detective, and responsive controls with ownership
+4. Data, secret, API, audit, vulnerability, and supply-chain protection
+5. Security testing, incident response, residual risk, traceability, and approval
+
+## Checklist
+
+- [ ] Are system scope, assets, owners, data flows, and trust boundaries clear?
+- [ ] Are identities, authentication, authorization, privilege, session, and
+      recovery paths covered?
+- [ ] Does each credible threat identify affected assets, impact, likelihood,
+      controls, owner, and test?
+- [ ] Are encryption, key and secret lifecycle, retention, deletion, masking,
+      logging, and audit addressed?
+- [ ] Are input, output, API abuse, availability, dependency, build, artifact,
+      and supply-chain risks covered?
+- [ ] Are security tests, incident response, evidence preservation, and
+      notification responsibilities defined?
+- [ ] Is every exception time-bound, owned, compensated, and accepted by an
+      accountable risk owner?
+- [ ] Can requirements, assets, threats, controls, tests, and implementation
+      locations be traced end to end?

package/skills/tech-writer/references/doctypes/system-design.md

@@ -0,0 +1,74 @@
+# System design type
+
+A system design explains how approved requirements will be realized through
+architecture, components, data, interfaces, deployment, security, quality
+controls, and operations. It must be detailed enough for implementation,
+testing, operation, and review without duplicating source code.
+
+## Target reader
+
+Architects, developers, testers, operators, security reviewers, and technical
+approvers who must verify that the design satisfies the requirements and can
+be built and operated safely.
+
+## Settle before writing
+
+- The approved requirements baseline and stable requirement IDs
+- The system boundary, design scope, environments, and external dependencies
+- The most important quality attributes and their measurable targets
+- Constraints on technology, deployment, security, compliance, cost, and time
+- The level of design detail needed for implementation and review
+- The owner of unresolved design decisions
+
+## Responsibility boundary
+
+Describe implementation choices and trace them to requirements. Do not
+silently redefine scope or acceptance criteria from the requirements
+definition. If the design exposes a missing, conflicting, or infeasible
+requirement, record it as an open issue and update the approved requirements
+through change control.
+
+Use `design-doc` or an ADR for one isolated decision and its alternatives.
+Use `system-design` when the reader needs the integrated design across
+components, data, interfaces, deployment, quality attributes, and operations.
+Its test, operation, migration, and security sections summarize the design
+decisions needed to understand the whole system. Split out a `test-plan`,
+`operations-runbook`, `migration-plan`, or `security-design` when that topic
+needs executable procedures, independent evidence, a different approval
+authority, or a separate lifecycle. When a standalone document exists, it is
+the source of truth for that topic; the system design links to and summarizes
+it instead of duplicating details.
+
+## Template
+
+Start from `assets/templates/system-design.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Agreement target, scope, assumptions, constraints, and design drivers
+2. Context, container, component, and processing-flow design
+3. Data, transaction, interface, and error-contract design
+4. Security, performance, capacity, availability, and reliability design
+5. Deployment, network, observability, operation, backup, and recovery
+6. Migration, release, rollback, test traceability, trade-offs, and approval
+
+## Checklist
+
+- [ ] Is the design boundary clear, and is the approved requirements
+      baseline identified?
+- [ ] Are major components assigned cohesive responsibilities with explicit
+      dependencies and interfaces?
+- [ ] Are data ownership, schemas, integrity, transactions, retention, and
+      deletion addressed?
+- [ ] Are authentication, authorization, encryption, audit, secrets, and
+      threat controls concrete and testable?
+- [ ] Are performance, capacity, availability, timeout, retry, idempotency,
+      backup, RTO, and RPO decisions quantified?
+- [ ] Are deployment, network boundaries, configuration, observability,
+      release, operation, and incident handling implementable?
+- [ ] Are migration, compatibility, rollback, and failure recovery covered?
+- [ ] Is every major design element traced to requirements and tests?
+- [ ] Are rejected alternatives, accepted trade-offs, risks, open decisions,
+      reviewers, and change history recorded?

package/skills/tech-writer/references/doctypes/technical-proposal.md

@@ -0,0 +1,49 @@
+# Technical proposal type
+
+A technical proposal asks decision-makers to approve a technical approach,
+budget, and delivery plan. It is broader than an ADR: it must connect the
+architecture to measurable outcomes, implementation cost, risks, and a
+recorded decision.
+
+This doctype is for an internal approval proposal. For a supplier's
+technical bid in response to an RFP, structure the response against the
+RFP's requirement IDs, requested proposal contents, pricing, and contract
+deviations instead of using this template.
+
+## Target reader
+
+The person or group accountable for approving the investment, accepting the
+trade-offs, and assigning implementation ownership.
+
+## Settle before writing
+
+- The exact decision or approval being requested
+- The current problem and measurable target outcome
+- Budget, deadline, security, compliance, and staffing constraints
+- At least one alternative, including the current-state baseline
+- The evaluation period used for total cost of ownership
+
+## Template
+
+Start from `assets/templates/technical-proposal.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Decision requested and executive summary
+2. Background, measurable goals, and non-goals
+3. Proposed architecture, data, and security
+4. Delivery, rollout, rollback, cost, and staffing
+5. Alternatives using shared cost, time, effort, and risk axes
+6. Risks, success metrics, unresolved questions, and decision record
+
+## Checklist
+
+- [ ] Is the requested decision stated before the implementation detail?
+- [ ] Are goals measurable, with an action if a target is missed?
+- [ ] Are non-goals, assumptions, and constraints explicit?
+- [ ] Does the comparison include a current-state baseline and shared axes?
+- [ ] Are initial cost, annual recurring cost, and TCO period comparable?
+- [ ] Are rollout, rollback, security, risks, and ownership covered?
+- [ ] Can the final approver, date, and decision be recorded in the document?

package/skills/tech-writer/references/doctypes/test-plan.md

@@ -0,0 +1,67 @@
+# Test plan type
+
+A test plan defines how requirements and quality risks will be verified,
+which environments and data are needed, and what evidence permits a release
+or acceptance decision. It covers planning and traceability rather than
+replacing executable test code.
+
+## Target reader
+
+Test leads, developers, product owners, business acceptance testers,
+operators, security reviewers, and release approvers.
+
+## Settle before writing
+
+- The approved requirements and design baselines
+- The approved security-design baseline and security test IDs, when present
+- In-scope systems, environments, platforms, and quality attributes
+- The highest-impact quality risks and required test levels
+- Measurable entry, exit, and release criteria
+- Environment, data, tooling, staffing, and schedule constraints
+- Defect severity definitions and residual-risk approval authority
+
+## Responsibility boundary
+
+Define the verification strategy, cases, criteria, ownership, and evidence.
+Keep detailed automation implementation in test code. A test plan must not
+weaken an approved acceptance criterion; record conflicts as open issues and
+resolve them through requirement change control.
+
+The test section in `system-design` is sufficient while verification remains
+an integrated design summary. Use a standalone `test-plan` when execution
+needs its own environments, schedule, evidence, release gates, or approvers.
+When both exist, the test plan is authoritative for test execution and
+release evidence, while the system design retains the architectural rationale.
+When a `security-design` exists, import its security test, threat, and control
+IDs. Preserve `SEC-TC-*` as the planned security-test identity and map it to
+the executable `TC-*` case that produces release evidence.
+
+## Template
+
+Start from `assets/templates/test-plan.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Agreement target, baselines, scope, quality goals, and risks
+2. Test levels, non-functional testing, environment, and data
+3. Entry, exit, release, and residual-risk criteria
+4. Requirement-to-test traceability and defect management
+5. Schedule, ownership, evidence, risks, and approval
+
+## Checklist
+
+- [ ] Are the requirement and design baselines uniquely identified?
+- [ ] Are scope, exclusions, environments, platforms, data, and production
+      differences explicit?
+- [ ] Does the strategy prioritize tests using concrete quality risks?
+- [ ] Are functional and non-functional criteria measurable?
+- [ ] Can every Must requirement and acceptance condition be traced to tests?
+- [ ] Can every applicable security test, threat, and control be traced from
+      the security design to an executable case and its evidence?
+- [ ] Are entry, exit, defect, release, and residual-risk criteria objective?
+- [ ] Are suspension and resumption conditions defined for blocked or invalid
+      test cycles?
+- [ ] Are evidence storage, ownership, schedule, and approval defined?
+- [ ] Are test-data privacy, cleanup, and environment reset covered?

package/skills/tech-writer/references/style-constitution.md

@@ -8,12 +8,13 @@ Sentence-level naturalness, vocabulary, and rhythm are out of scope here
 
 These 8 rules assume a **living, multi-section reference document** —
 README, design doc/ADR, API reference, release notes/CHANGELOG file as a
-whole, user manual, Zenn/Qiita article. Apply all 8 rules to those
-doctypes. For Zenn/Qiita specifically, rule 1's "title" lives in YAML
-frontmatter rather than an in-body '#' heading — see their doctype
-reference files for the platform-specific frontmatter fields — but every
-other rule (heading hierarchy starting at '##', code examples, disclosed
-limitations, etc.) still applies verbatim.
+whole, user manual, technical proposal, RFI/RFP (including a supplier's RFP
+response), or Zenn/Qiita article. Apply all 8 rules to those doctypes. For
+Zenn/Qiita specifically, rule 1's "title" lives in YAML frontmatter rather
+than an in-body '#' heading — see their doctype reference files for the
+platform-specific frontmatter fields — but every other rule (heading
+hierarchy starting at '##', code examples, disclosed limitations, etc.)
+still applies verbatim.
 
 **Atomic, single-purpose artifacts** — commit messages, PR descriptions,
 issue reports, code comments/docstrings, and a single new entry appended